LUKAS:
Wait for it!
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Ready to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours classes in St. Louis or San Francisco – AngularBootCamp.com.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “Angularadventures” you'll get a $10 credit!]
[This episode is sponsored by Telerik, the makers of Kendo UI. Kendo UI integrates seamlessly with both AngularJS 1.x and 2.0. It provides everything you need to integrate with AngularJS out-of-the-box bindings, component configuration and directives, template directives, form validation, event handlers and much more and yet Kendo UI tooling does not depend on AngularJS. So if you want to use it with Angular or not, that’s totally up to you. You could check it out at KendoUI.com]
CHUCK:
Hey everybody and welcome to episode 67 of the Adventures in Angular Show. This week on our panel we have Lukas Reubbelke.
LUKAS:
Hello.
CHUCK:
I’m Charles Max Wood from Devchat.tv. This week we have a special guest – Jesse Warden.
JESSE:
Hey, what’s up?
CHUCK:
You want to introduce yourself?
JESSE:
Yeah, so I’m Jesse Warden. I’m a technical architect manager at Accenture and I do a lot of client side JavaScript and struggling to do more Node, a [inaudible] for my desire anyway.
CHUCK:
Very cool. Before we get going too far, I did forget to mention one thing and that is that we have a new topic suggestion system, so if you want to check it out, it’s on GitHub – github.com/devchattv/aiatopics. We’ll get you there and if you have any recommendations, you can put them in there. You can also +1 other people’s topic suggestions so go check that out.
So yeah, we brought you in today to talk about consulting in Angular and some of the challenges that you see your clients facing. I wonder, is consulting in Angular much different from people who are full-time employees working on Angular apps or is it a different type of person that is contracting that out?
JESSE:
Yeah, major difference. I think most people who are working on apps or [inaudible] software companies where somebody in leadership has a desire to put the user first somehow. They want to make money but they also realize they have a product or some kind of service that relies on being good. So they care about things like software quality and put it as a priority and that naturally rolls down to those in the trenches.
Consulting usually is for people who have software not as their core business, or are just having challenges because it’s part of their business but they just don’t have the leadership and place for it or need extra help, they need somebody to get them on stock or from that perspective. So a lot of our times is teaching basic software stuff, basic DevOps, basic testing practices, basic UI design – types of things like that as well as trying to help people either get projects on stock or just helping them out; one of the two. So it’s a lot of problem solving, a lot of people skills not just actual software writing.
LUKAS:
And not only that if I could jump in; a lot of it is something’s already gone horribly wrong in a lot of cases and you are showing up and you have to very quickly figure out the context. Whereas as a full-time employee, you are generally [inaudible] to a lot of the meetings and the dialogues that led up to decisions that got them into that place. Whereas it’s always interesting as a contractor, you show up and it’s like ‘this thing is totally up for Rails and we need to fix this as soon as possible’. And you have to try to put the pieces together, figure out what actually happened without any of the context that led up to it.
JESSE:
Yeah, some of my old jobs were like that. Once I started running my own firm and having at least three or four people declaim that I was a reasonably sized company, some of the projects we get, they weren’t actually [inaudible] but we could at least dictate some of the stuff from the front end. So we weren’t allowed to mess the backend; we were allowed to change API layers but at least we could be part of the solution, not part of the problem. But I definitely been in this kind of project where you said you come into some third party, two weeks to figure it out, you try your best to get up to speed and help recommend things and they’re not really receptive to listening to things because it’s your first week there, so you have to prove yourself by fixing bugs to earn the trust, to make the recommendations.
So it’s a very challenging thing when you walk in to this kind of project. On the other hand, because you’re a third party, sometimes you can get away with saying things that an employee couldn’t say, you know what I mean? Because it’s like if you’re not in my company, you’re just a client, I’m trying to help and if you don’t want to take my advice, that’s cool. Based on my experiences, this is what I’ve seen and my suggestions are here. If you don’t take them, I really don’t care; I just want to make you to win. Sometimes, you can get away with saying that where, as an employee it’s hard to do that.
CHUCK:
Yup, so what are the cliffs that you’re pointing out? Like danger, that way, don’t do that.
JESSE:
I think the biggest problem is the same problem I’ve seen in every single software project and that is just that most of them, if you look at the rating system, we have level five through level one where level one is cowboy coding like designing [inaudible] who never pay their technical debt. All the way up to level five and six, the company’s at launch NASA rockets and the Challenger Systems and all that kind of stuff who have really, really hardcore quality programs.
A lot of companies are still around the two and three where they just don’t have any size of DevOps or anything like that, they don’t really care or understand that you have to have quality first, you have to automate it so developers will do it – that’s one problem.
The second is that front end is very new for people. Even in the Flash and Flex days, the Java developers loved us because we could – there’s thirty of them and one of us. So they can handle all the API layer and we could work to share everything and it took a lot of burden off them. But now, you got a lot of these hybrids where the Java developers would be some of the front end or some of the C# guys and they don’t have any UI background. They’re not used to – these are the kind of people that ask you to do red-black trees on interview questions; when you ask them to do an infinitely scrolling list they go ‘why is that relevant?’ [Chuckles] Why is it relevant? That’s what they do all day – I don’t reverse black ridge or whatever they’re called. So that’s problem number two.
Problem number three is I’ve never fixed this but it’s struggling to involve the user even if you have a really good lead engineering DevOps process and trying to get designers’ vision actually implemented in the UI and have them in this feedback loop. Traditionally, that’s not there and so those three are just really hard to fix, to advice on, to get a system around, customize for the company, blah, blah, blah.
LUKAS:
So I have a question with a bit of an anecdotal back story to lead up to this. So Jesse, I think we’ve known each other for maybe seven, eight years if I’m not mistaken. And we first met when I was burning Flex for the first time and making that transition from ActionScript to Flex, and I remember I said, “Look, here’s $100, just tell me if I’m putting my Flex project together correctly.”
I remember we spent a little bit on talking on the phone and I kind of got straightened out but it was really interesting that Flash and Flex went to this painful growth period where it’s like, “Okay, it’s time to grow up into a platform,” and so we’re going to go from ActionScript 1 which is very similar to ES5 to ActionScript 2 and 3 which had a little bit more classical sugar on top of it. Now, we’re almost on the same spot again where JavaScript is going from ES5 to ES6 and even more so with TypeScript where now with the super super set, you have things – inheritance or rather interfaces, typing in these different things where – just last week, I was showing some Java developers Angular 2 with TypeScript and they’re like, “Oh, this makes so much more sense than regular JavaScript and Angular 1X.”
So I’d love to hear your opinion about how these cycles that you’ve seen from ActionScript 1 to 2 and 3 to now where we are with Angular 1 going into Angular 2 with ES6 or TypeScript.
JESSE:
That’s a gigantic question. Part of the reason I disappeared for three years with Corona and [inaudible] was because I was hoping that by the time I came out, everyone will assume that TypeScript was the way forward and it wasn’t. It took three or four years not only to be relevant but to basically make Google Dart look old, right? So that’s pretty impressive they did that but the thing is to be like three camps in JavaScript which is interesting. We had two in the Flash [inaudible]. We had Flash designers and developers in [inaudible] and then we had those using Flex. For the most part that was the stereotype – it was accurate.
If you’re going to [inaudible] large systems for enterprises, you’re using that. And if you’re doing design or really short deadline, you don’t really care about best practices because you’re being creative, you don’t have any technical debt, you never paid off – that was Flash. JavaScript uses this third realm of functional people who are very into React and Flux. They seem very alienated by TypeScript.
We have a small user group in Richmond so it’s not really indicated with the industry, but even there, there was still some functional people who thought Angular looked extremely complicated. And not all of them were from a [inaudible] background so it’s interesting that there’s three for people who do jobs from the ancient world, there’s room for them to use something like jQuery or Polymer or React then call it a day. And then here’s room for the functional people like in Netflix where they’re doing Flux and RCS and Falcon and all those things from a functional perspective to build apps as well as people like me who work with traditional C# developers who are used to OOP, and Angular and TypeScript feel right at home for us doing the declarative, doing components.
So I think it’s interesting that it has somewhat the same parallel but there are thousands of more people that build systems that are insanely better, the tooling is insanely better, there’s tons of more options. And now that I have context of watching the change, I think we are in a much better place than we were back in the day with Flex and all that stuff.
The run time is not so great in terms of views and stuff, the way I want to compose UIs but I think from a developer’s perspective the tooliness is immensely better. From TypeScript, from the build systems to the unit test frameworks to the packaging systems and to the thousands of people online who basically produce these stuff for free, that’s just really nice. We didn’t have that back in our day because of the size of our community.
LUKAS:
And so in these corporate settings, what has been your experience in terms of what’s in the pipe line with Angular 2 and TypeScript have –? [Crosstalk]
JESSE:
Well, that’s complicated. I’ve worked for three different clients within Accenture that I would consider a reasonable indication of who their clientele is and they’re very similar to what I did with Freelance but they’re just a little bit bigger in terms of how much money is on the table.
So same type of clients, just bigger products. And each one was different in terms of the enterprise context. One was a bank; it was very design heavy. They like branding, they got it. They hired designers who were intimate with SaaS and LaaS. They believe in designer-developer work flows. They believe in prototyping and trying to mash Waterfall and Agile together to get something out.
So from that perspective, it wasn’t a matter of selling; it was more about getting the work flow with developers who don’t care about design involved in that or [inaudible] from that which is cool. It’s the same problem – Flash and Flex. So that was one challenge which is a good challenge, getting the work flow down [inaudible].
The second client was more of a media client. So they were a little bit easier from a perspective of working with the tooling but I think the issue we had was that we were training up a lot of different people who don’t have this background. They don’t know why Angular double binding can be bad. They don’t understand about state machines. Even the basics of programming, they’re trying to do that.
And then number three is – the other client, they don’t have any view representation at all. They don’t understand the ecosystem so trying to teach them like – things have changed from the ‘90s. We don’t use SPN and some of these old things anymore; the world’s moved on. So trying to even teach them the basics and say that this has nothing to do with JavaScript once part of this larger ecosystem.
It’s been a lot of educational evangelism and things like that and trying to put it in an objective way rather than saying ‘it’s cool’. Well how is ‘get cool’ than SPN? Can you be more specific? We’re trying to quantify that the world hasn’t done. Can you give me a factual statement of that? Can you give me a Gardner white paper that clearly says that? That’s been very difficult to quantify that in a quantitative way rather than feel good stuff that we find on the internet.
I think each one of those clients has either a work flow problem, integrated designers, a teaching problem, trying to bring new people up to speed and make sure they don’t hurt themselves or they have a significant DevOps problem. We’re trying to get general, continuous integration [inaudible] delivery up and run with on-site hardware is awful. Those are the three things that have been really, really hard. In Angular, it’s like – who wants to be a part of that?
LUKAS:
That’s actually funny you should mention that. Last week I was on-site for an assessment for some training and it’s like, “Okay, we’re going to do Angular training but let me just spend two days meeting the team and just seeing what’s going on and then we’ll come up with the best course of action from there. And I spent probably 90% of my time actually talking about Agile and work flow and how to get designers to work with developers and straightening that out.
Like you said, Angular was just such a small part with those discussions that a lot of times with the large, entrenched, corporate developers, there’s a mindset shift that has to happen first which they’re wrestling with that on top of actually take a traditional C# or Java developer and move them to the front end and then teach them this new, wild thing called front end development.
JESSE:
Yeah, I have been to that. The other half is trying to find the passion. A lot of them are, like we talked before, in a negative situation. Some of them were just not as passionate about this I think because a lot of the companies don’t have career paths for developers. So eventually, after five years goes by and the products matured, those developers either move on to other companies or move out in positions where they get away from technology. And for some career paths, it’s fine. People want to move up; they want to move out of software development in the sales or management. But a lot of us who want to remain techies for life, there’s only a few companies that encourage that culture and want to retain that talent and magnify it for leadership regions. So a lot of the companies they go to don’t have that in place.
So ten years from now, Johnny starts as a coder at a college and he wants to continue being a coder, what is his career path? Most companies can’t answer that. They assume Facebook and Google will take these kids and everyone’s going to move to California and that’s just not sustainable. Some people want to live on the East Coast and work on a company where they can positively impact their organization.
Some developers do it but they only do it for companies that appreciate what they have to offer. So a lot of these managers that ask you, “Why do you want a developer in a room with these people writing user stories?” And I’m just like, “Hold on; I think the bar’s still open. Let me go drink, I’ll come back and then we could talk about why that was the most ridiculous question ever.”
It’s very, very frustrating to start with process. I hope we’re going to go there and code and I would do some Angular and teach them some DevOps, and instead my job is trying to explain basic, casual, lean engineering processes with DevOps and CICD. This is really basic stuff.
The other worst thing is the same problem that I had with Ruby on Rails is that some people don’t know the fundamentals. There’s this really horrible expectation from C# to Java developers who’ve been in “web development” for years that when we – we actually have internal training programs at Accenture and a lot of them say they know JavaScript. And when I asked basics about the global variables or functions or closures or scope or difference between prototype and a closure or dealing with encapsulation – all that stuff. They have no idea what I’m talking about. And so a lot of times we have to teach them Ruby before you teach them Rails. In this case, we have to use some JavaScript before we teach them the ecosystem, which is a lot of work because they have a style of thinking which I agree with – I came from an influenced Java background but on the other hand, you have to give me options to say, “Look, if you want to do it from a more functional way, here’s your options.” That’s hard because there are so many options for JavaScript. It’s not dictated. Even Angular 2, there’s like four bloody language offerings. That’s not helpful. I know they think it’s cool but it’s not helpful.
LUKAS:
I second that motion. Well even to that point, it’s funny with Angular that it actually abstracts a lot of the bad parts. So by having a dollar scope, you don’t have to necessarily thing of JavaScript scope in it being leaky. It solves that problem for you. So there’s been a few times where I went back to JavaScript and it’s like, “Oh, right. This. This actually leaks,” or this is no longer accessible.
Whereas scope in Angular, that [inaudible] scope is very good at actually preserving context and guessing what it is especially in an ng-repeat and everything so we’ll actually establish that scope in that context for you. So all you do is Angular, it’s really easy to not understand how scope and how the closures and these different things actually work under the hood.
JESSE:
I did a presentation last night about it and there’s a lot of things to love about Angular 2. It’s a lot simpler in terms of goal components. There’s no such things as, in terms of factories and services on, basically make classes, right. So allow this to go away but even in ES6, if you don’t follow basic verbal hoisting, you’re still going to have scope problems.
So there’s still – unless somebody establishes best practices like John Papa did with his style guide; unless you have some kind of – included best practices on the Angular.io website, that’s not going to percolate down to the general populace and they’re going to start bad. Or if we have a Yeoman generator handle that for some of the basic – either Dart or TypeScript or ES6. Unless that started from day one and engrained in the Angular community like, “This is how we should do things,” then I think some of the problems will still stick around just based on what I’ve seen since [inaudible] when people are using this and expect it to work.
LUKAS:
Right. Thankfully John Papa is working on an updated Angular 2 version of his precious style guide. [Chuckles]
JESSE:
Good.
CHUCK:
Got to love that.
JESSE:
We have an IBM guy talk to our internal architect conference. We have this internal architect conference and you have to be certified by Accenture to be invited. I was invited because I was speaking so I’m not certified yet but it was interesting to having this guy from IBM basically talk about the biggest challenge of companies right now is you can’t out-innovate. And I maybe got the numbers wrong, but he said the Oracle conference in the United States of America had 6,000 attendees or something. The same year, the OpenStack in Spain had 22,000. And he’s trying to get the point across that all of these open source is out innovating and out developing and out – this is what people use.
So part of your stack for business is basically picking a stack that we believe in and promote it. However, there’s still a lot of people who still has to use Backbone for backward support, reasons – things like that. There’s still people who use React just because that’s what the want to use.
And so we have to adjust the stack for that. And I think John Papa’s Style Guide is a very integral part of that because when you say ‘use the stack’, you’re like ‘how do we actually code it’? And unless you have those white paper guidelines like we had on Flex on how to do that, Google has their JavaScript ones on white paper on how they suggest that. I think we need something a little more official. John Papa’s cool but it needs to be we’re gained by Google with cited very clearly otherwise, you’re just going to have people doing everything differently which is okay and the four different languages but it’s not going to be okay if we’re going to start with ES6 which is the safest option.
LUKAS:
Wow, that was deep. And yes, John Papa is very, very cool [laughter].
JESSE:
We’ll make fun of him on Twitter and see if the show’s up.
LUKAS:
Yeah. So I feel like I’ve been yacking and dominating the show. Chuck, Aaron, would you guys like to jump in and take a shot at this? Jesse’s just unshakeable, man. He’s just a stone cold killer.
CHUCK:
I can chime in a little bit. I’ve talked to a few clients lately who when I bring up Angular, they are a little bit scared still of the whole Angular 1, Angular 2 dichotomy and, “Whoa, what if we start with Angular 1 and then we’re in Angular 2.” Even though I explain to them that since Angular 2 isn’t out, Angular 1 isn’t outdated technology, they still don’t buy in just from the fact that they feel like Angular 2 is right on the doorstep and they don’t want to fall behind immediately when it comes out.
AARON:
Angular is still your best bet for that. When you look at – because a lot of people are already on Angular 1 and then I [inaudible], we ditched Angular and go to something else. I don’t think you should because if you want to switch to some of the framework, you’re going to have to write all these bridges manually to buying your [inaudible] the other to the new framework because you’re not going to be able to convert your entire app from Angular 1 to this new thing; you’re only going to be able to do the new pieces.
But with Angular 2, they’re going to have it to where any other one can run beside of it and vice versa. So I think that your conversion story for those kind of people is where you sell them and say the Angular 2 is actually going to provide those bindings and those bridges so that the two can coexist, and they’re going to give you a migration path that you wouldn’t get with any other framework. It’s actually a pretty sweet deal that they’re offering.
CHUCK:
Yeah, I have explained that to people and some people will buy into that but others, because it’s consulting as opposed to having somebody on site that’s going to work on your crap anyway, they see that as more hours or more time or more cost that they’re going to have to put into the project rather than just waiting or adopting something else that theoretically won’t change in the mean time, which I also explained to them, everything’s moving and moving, it break that speed and the JavaScript space so there’s no guarantee that by going to React or Ember or Knockout or something else that you’re not going to have exactly the same issue.
AARON:
Yeah, so far the only sure bet is JavaScript and Node for build system – that’s it. Everything else is completely up for grabs.
CHUCK:
Well, and even then, which JavaScript?
AARON:
Just regular ES5.
CHUCK:
Right, but for how long? Eventually ES6, ES7, ES2015, 2016 – whatever. Those are eventually going to become the new standard and they're going to drop backward compatibility from the older versions of JavaScript, don’t you think?
JESSE:
To give you context, Lukas can totally attest to this. Some of the work that I did back in the late ‘90s, in early 2000s you cannot see even if it’s not behind a firewall, it’s gone. There’s no way for you to physically see it.
However, space jam and the first website ever created on the internet still work in Chrome, Safari, Firefox and Opera and on my phone and that’s kind of a testament to web standards much to make fun of them and things like that. I just retweeted actually at that Dalton guy that works on lodash, he's trying to - he's struggling for all the 20 year olds to say ‘I don’t need this now' because array for each is already available in the browser natively. They don’t need lodash, it's good – I'm done, and he's explaining like it's not that simple. Even with ES 6 or with SystemJS and all these bridges, the stuff he wrote are still going to work; you don’t need to worry about it.
But if we’re telling our clients, if you want better features they’re definitely out there but as Aaron was saying, the bridge is not that bad, it's just all depends on what you’ve already built.
CHUCK:
Yeah.
LUKAS:
So to second that is I’m starting a new project with a client and our timeline is 2016. And they’re Java developers so once we started talked about options and I said, “Well, Angular 2 and TypeScript, interface typing, etc,” and their eyes lit up and they said, “You know what, that timeline actually works for us.” Whereas with another client they actually have to have something done at the next couple of months. So we made the decision to go with ES 6 in Angular 1X but that provides the same kind of upgrade path down the road because it is in an Angular 2 style.
JESSE:
Yeah, in the past we would have six months update cycles for Flash player and we would play in some new features. Now, we can use features that aren’t even out yet and how all these transpilers and all these other build systems work them in and we can get rid of them over time; somewhat offload to the native browser functionality.
Some of these browsers now have one month transition cycles to update so a lot of those planning for release cycles can work. However, what we’re trying to pitch is that we should have weekly release cycles, not 2016. So we should be able to not necessarily change our architecture from Angular 1 to 2 but we should be able to deliver something now, and if we want to change it later, we should be able to. But I think based on all the stuff I’ve seen in Angular 2, most of the stuff that I tested works pretty well. So I don’t see why we can’t start now if we had that long of a deadline.
CHUCK:
So one other thing that I ran into a lot as a consultant myself are maintenance issues. So either I
wind up taking over maintenance for somebody else’s deal or I write something and then they decide that they want to go with somebody that’s lower cost, that’s willing to take on a project only a few hours a month to do the maintenance. And the way that I write Angular isn’t always the way that other people write Angular. Similar for Rails and whatever else I’m using in the project or CSS. The way I arrange things isn’t the way that other people arrange things. How do you optimize for that with Angular?
JESSE:
Well, I work for Accenture and part of our business model is low cost, offshore development. So we have offshore resources on the same time zone; we have offshore resources all over the world for different geographies. So a lot of that cost is factored in to whatever we’re developing. We know that we’re going to have maintenance and some of it’s going to be the client – on set employees. You help dictate the direction, the architecture that they’re comfortable with.
But part of the RFP process is putting together a deal that you know factors that into play. So we can provide resources that know JavaScript, that write the way that we want to, can use our architecture, our DevOps or generators – whatever best practices we suggest to follow. But they’re not as expensive as manager consultants who live in America.
That’s part of the stick I have. Where I was previously consulting, I don’t know how to fix that. Usually, I would do the best I could to makes sure that I provided ample documentation, I make sure the build was working, I provided known – as much logs as possible so if something went wrong, that was known. A new developer would understand what the context was from exceptions or logging things. I don’t know if that helps but I never had clients get mad and call me for help. I never forget how to solve that when I was in a smaller consulting firm. With the larger one, we just provide cheap resources for it.
CHUCK:
Yeah, and where I usually come in with a lot of these is I’ll follow some particular style guide. So I’ll do John Papa’s style guide on Angular 1 apps and I will do – there are a few Ruby on Rails style guides when I’m doing Rails and I’ll document the way that I am arranging my SaaS or CSS or however I’m managing all that less – whatever. Bootstrap, etc. In that way, people know it’ll all follow this general format.
And then as far as the rest of it goes, just good naming, good documentation, letting people know where stuff’s at and then yeah, I really like the idea of hammering out. I ran into this issue and I
solved it this way.
One other thing that I’ve done is I’ve actually put issue numbers and issue explanations into my Git messages and then let people know that that’s a good place to look as well. In that way, they can just look in their Git log and then find that particular commit then they can go look in GitHub or whatever if that’s more convenient and actually see what the code changes and where to fix the issue.
JESSE:
That’s a good idea. Most of the source control stuff I’ve been with, it’s usually been a mess. I’ve only been on two clients that have actually had Git and only one of them had GitHub enterprise. A lot of them had some old version [inaudible] or something; it was just really gross. And not everyone on the team was adept at using my command line.
So the other problem too is the leadership in place when I leave is always in question. If that company has good tech leadership, I really don’t have to do a lot because I know –.
CHUCK:
That’s true.
JESSE:
You know what I mean? I don’t have to worry so long as you do X, Y and Z. Whereas, some of who are going to have to maintain this for years, they have an expectation that one or two developers who does everything – the jack of all trades who’s been there forever. That I had to invest more work because they are expected to handle everything. Then the contract clients, the ones who I
build products for, I’ve been lucky that most of those were only three to four months project so the projects weren’t that big, they only had one to two developers. The code bases were not that complex so I didn’t have to worry so much about those exploding, and if it did it was something really small that I had no problem doing a change [inaudible] for, like a really cool contract that says, “Hey, it’s a couple hours; no problem.” Or like my father did, I would bake it into the original statement of work so you get 10 hours to 20 hours of my time over the next three years for support. And hardly ever do they ever use that but they like to know that id drop everything that I would do on a Sunday and help them if they had a bug.
CHUCK:
Yeah, my contracts usually look a little bit different than that rather than promising a certain number of hours. If I can, I’d contract the outcome so you will have a system that does X, Y and works to this level of reliability. And then when you sign off that it’s done, but at the same time the understanding was that I contracted to give them that outcome so if there is a critical bug that comes in later that they find, then I feel like under my contract I’m going to jump in and make that right because otherwise I’m not delivering on what I promised in the contract in the first place. And then I just collect the bid and they don’t pay any more money.
JESSE:
I would never do that. You must have really nice clients; mine are brutal. Part of the reasons I want to do Accenture is that I’m so exhausted from eight years of collections and struggles dealing with some of the larger endeavors. We were very brutal on the statement of work being in our favor and even then I’ve never had a client nickel and dime me about that kind of stuff. Like I said, I would put 20 hours and use it but I’ve never seen – and maybe this is just my paranoia – I’ve never been able to deliver exactly to that level of quality because there’s always bugs, there’s always a change request in the middle of that. They say, “Well, it’s out of scope but this is what we want,” and I’m like, “Okay, I’ll just do it rather than just change the contract six months in the project.”
CHUCK:
Yeah. My deal is I would much rather collect up front because that solves all the collection issues, tell them I’m going to deliver whatever I’m going to deliver, and then if it turns out that the discovery process that we went through initially didn’t uncover something, or as we built it we found that we needed something else then yeah, we just negotiate the contract and then they pay the difference up front and then they just get what they want.
And then it’s not this ‘oh my goodness, we got this half done and we’re out of money’ or any weird stuff like that. And I don’t have to log on my hours and nitpick all that crap. I just get in, I get the problem solved, I make them happy and then I leave.
JESSE:
Well next time I get tired of working W2 and I go back to consulting, I’ll make sure you’re my sales guy. [Laughter] You can write on my contracts and be my client delivery lead.
CHUCK:
It is a lot of work to do at that way and for the larger clients, I would actually tell them, “Look, I’m selling you a discovery document,” and they will actually pay me for the upfront discovery work. But most contracts weren’t large enough to really merit that; we just spend a day or two, we hash it out, make sure that all the questions got answered and then I do a bid. The first few you do that on, you kind of lose your shirt because you realize that you didn’t ask enough of certain types of questions but after a while you’ll figure all that stuff out.
I have a whole podcast that I talk to people about this on. If you’re interested in freelancing, go check out The Freelancers’ Show. We talk about a lot of these stuff on a regular basis.
JESSE:
That was part of my desire for Accenture. They said, “Why do you want to work here?” and I said, “Well, you guys have sales people?” And they said, “Yes.” I’m like, “Okay. Do you have collections people?” And they said, “Yeah.” I’m like, “Cool. That’s why I want to work for Accenture.” And they thought I was joking or being uncomfortable like ‘don’t you want to code? Don’t you want to work with good people?’ Well yeah, it’s a given. I’m tired of doing contracts and I’m tired of doing collections and I’m tired of doing sales on the weekend. And once I talked to a fellow consultant who work there, he knew exactly what I was talking about. Part of the job interview promise I had is people who traditionally deliver software forget that there’s a business aspect to it, there’s a peoples aspect to it and it’s a lot of work. Those hours are like real hours doing real work that’s not related to code.
It’s just been nice to have – all those things you said actually in the contracts, now is no stress. I can actually do my work and not stress about it.
CHUCK:
Yeah, I also have to point out though that I have other things that bring me money like the online conferences and I get a little bit off of the sponsorships. And so I’m a little bit – I can afford to be a little picky so if they’re not a really good fit for that type of a bid then I won’t take the contract.
JESSE:
Right, because it’s not like I have to suffer this kind of payment mortgage; they’ll do it, right? [Laughter]
CHUCK:
Right.
JESSE:
I got you.
CHUCK:
Frosty, do you have any questions about consulting in Angular?
AARON:
No. Sounds like a nightmare. [Laughter] I work on a humongous app so I end up working with a couple of guys. We kind of consult internally about – I’ve never tried to do what you guys are doing. I did it one time but it was [inaudible] two days so I don’t know how you guys do it full-time. It sounds really intense.
CHUCK:
It’s definitely a different type of work and you have to be really careful to not wind up owning your job which is what it sounds like Jesse did to a certain degree. Because if you just own a job where you have to do all the parts that you don’t like and all the parts you do like then a lot of times it’s not worth it even if you make more money or you feel like you have a little bit more flexibility on our schedule. You get some of that but you lose some of that, too.
JESSE:
Yeah, I think the career desire for consulting was like once you’ve built enough apps, there’s only two – as far as I knew, two paths left. You can either go to the startup route where a bunch of different [inaudible] and say, “Look, I’ve done this so many times. Not only can I do it from scratch but I can do it for someone I don’t know and I can do it while doing something else like management or marketing or talking to investors” But whatever that is and that’s very, very compelling for some people who are so sick of being dictated architecture and dictating technologies that they don’t want to use or they just have a desire. So that’s one path.
The other path is consulting where you already know how to do stuff so you can help people who know a really specific business but they don’t know how to do that you say from a best practice perspective. Or you have a team that’s off track and you just help them a little bit. It’s a very little investment of your time but it’s all about people. As an extrovert, I love working with devs – not so much code. [Inaudible]
CHUCK:
[Chuckles] Yeah.
JESSE:
So like John when I work for them briefly we never got anything done because I was just talking to him at lunch.
CHUCK:
Yeah, I hear that. The other thing that I hear a lot and it’s kind of a specialized consulting is specifically training. You have people that make courses or other info products that are training products or they wind up going on site usually for larger companies and saying ‘here’s how you solve your problem with whatever technology’s that I’m an expert in’. And then there are the people out there that really just figure it all out. They don’t mind the marketing, they get a system in place where they don’t have to do a whole lot of the uncomfortable things like collections or salary – not salary but rate negotiations and things like that. That or that stuff just doesn’t bug them and they get to work on the technology they think is cool.
JESSE:
Yeah, the only person I met that did that was [inaudible]. He was originally created one of the first component frameworks in Flash and then he eventually created his own – he works at a couple of startups. And he was one of those CEO guys that could negotiate rates and he didn’t have a hard time. He wasn’t stressed, it was not a big deal for him but he was so intelligent he still understood coding. So he could switch gears where he would talk to a developer and then he’d go, “Alright, so basically this contract’s wrong and you’re asking too much money.” The ability to switch gears like that for me is fascinating. Just his personality type was great plus I take everything personally because I really care a lot. The people I’ve seen who’ve done that are just very calm, collected, not emotional, don’t take it personally, don’t sweat the small stuff. And I haven’t figured that out yet.
CHUCK:
Yeah, I can tell you that both Eric Davis and Curtis McHale who have been on the Freelancers’ Show panels for quite a while, neither on right now. Eric I think is going to come back here pretty soon. But anyway, the way both of them work actually is they have basically set rates and they negotiate that and if you can’t pay the rate, then you’re not a good fit and I’m really sorry so it’s not personal. If you don’t pay then they don’t do any more work for you and that’s just the way it is, it’s not personal.
They basically have a system and if you don’t fit into the system then you’re not my client and it’s not personal; that’s the way I work, that’s what makes me comfortable and it doesn’t make you wrong, it doesn’t make me wrong, it just makes it so that I can get the work done in the way that I like to do it.
JESSE:
That worked out really well for me, those two things. I didn’t [inaudible] as well but I definitely said I don’t negotiate on a rate, I try to be the most expensive person. And if you don’t pay, it’s cool; I’m just going to do something else. It’s not personal; this is not a charity. But for the consulting stuff, I
was always trying to grow. I wanted to bring a bigger team to the table because I wanted to do bigger things. I was tired of doing staff aug or how [inaudible] products. I wanted to build something big. And doing that consulting, you really have to always be selling not just coding and that was very hard for me. I’ve got to go learn Browserify because I got to fix the bill because nothing works here but I should probably be selling it instead.
CHUCK:
Yup.
JESSE:
And trying to – okay, I’ve only got 80 hours this week; how much can I really do without getting exhausted?
CHUCK:
Yup. Have you read the E-Myth Revisited?
JESSE:
I’ve read part of it. I think back when I first started looking for startups like [inaudible] and I was getting in that stuff, too. He sent me a bunch of books and I think that was one; I remember a part of it but I think I was – [inaudible] that Flash died, I’m like I’m done. I’m go on [laughter], I’m going to come out every year. When it blows over, I’ll read all these books and start a startup but instead of going to California, we actually moved to Richmond, Virginia for family reasons. So I was like, “I’m just going to get a W2 and recharge.” You know those bars in the video games? I’m 80% there. So I think it’s been 90% is when I start picking up the books again so I’ll finish it.
What’s the good part though? Where should I start? Because I don’t read books from start to finish so where should I start?
CHUCK:
This one, it kind of builds on itself in a particular way. You may want to – I’m about halfway through
it so I don’t know. The first half is –.
JESSE:
So I should start from the beginning? Okay.
CHUCK:
Yeah, but the essential bit is that there’s the technician, the manager and the entrepreneur in each of us. And most developers I know, they really fall under the technician – they want to get in and so the stuff and that’s the valuable part is doing the stuff. So yeah, you recognize that the manager in you is saying, “Yeah, I probably should be selling so that I can eat next month or two,” but the technician in you is saying, “Yeah, but I go learn Browserify then I can solve this problem right now,” rather than looking at it and saying, “I can go find somebody who understands Browserify and have them solve this problem right now, and then I can go sell and we can bot eat this month and next month.”
JESSE:
yeah, I was lucky to be with the team that had a lot of better closers. I was really good from an evangelism marketing but when it came to contract negotiation, some people – they might say they don’t have the money but they have the money, they can find the money. It’s just the matter of – [crosstalk].
CHUCK:
They don’t want it enough.
JESSE:
Right, and you’re just trying to figure out what’s the fear, what’s the trust issue and I think I just – I think in retrospect, most of the clients that I was dealing with were consulting from an angle of multiple vendors and I just wasn’t represented as a vendor. It’s more of I have a bunch of cheap friends, you know what I mean? You’re really smart; I’m getting [inaudible] rates but rather than being a partner. I think a lot of the – some of the stuff I read that and some of the other marketing books were saying if you don’t approach it as ‘we’re a team’ and ‘we’re here for you to work together’, it’s just me and the trenches. Like Jesse’s really busy in delivers but what else does he bring to the table? Himself. That’ not [inaudible] valuable.
CHUCK:
Yeah, there are a lot of different ways that I’ve seen it presented. Honestly, I think I have to figure out what works for you and works for the people that you’re trying to get in front of and get to hire you.
JESSE:
Whoever pays insane amounts per hour, he’s the goal.
CHUCK:
Yeah, but that’s not specific enough to know who should I be targeting so that I can get in front of them and have a good chance of closing and solving their problem, making them happy and getting referrals.
JESSE:
We tried that with dashboards. We had like a dashboard and so we say, “Look, we can wire a bunch of orchestrated data together on the client side,” so you can get insights to big data and we had some – half of the charge were just static, just drag and drop. It wasn’t anything sophisticated but the other ones was we put in together in such a way that it was architected where the Java developers could easily in enterprise drop it in, sell it to their manager and then they’ll call us when they struggle to get it building larger than a couple of days.
So we got a lot of referrals from that and the financial clients and the insurance clients are great because I had tons of money, they were really relaxed in terms of delivery and things like that because they just – they were used to quarterly releases which is ridiculous. Quarterly releases but the RFPs would take two months but once they were signed, it wasn’t a big deal. We could go there, we could build time and materials and it wasn’t a big deal but that was only 50%. The other clients theirs was random. They would find, like you were saying, conferences and stuff. They would find it from blog posts or Twitters and referrals so I never really got a stead type of client beyond the financials.
CHUCK:
Yeah, and see what you should’ve done is you should’ve told everybody else ‘no’ and then doubled down on the insurance and financial clients.
JESSE:
Yeah, maybe I should. It’s attention span – I’m working on stuff longer than six months like I do. [Crosstalk]
CHUCK:
no, I get that but yeah because then you know how to speak to the financial clients, you know how to speak to the insurance companies. You know what their concerns are because they’re all pretty similar and you can address a lot of that stuff specifically and not go through sales cycles and trying to figure out why the conference or whatever else isn’t biting on what gets your other clients really excited.
JESSE:
You’re so right. I remember some of the sales calls progressively were more and more shorter because they were like, “What about dealing with the vertical blah?” And I was just like, “Well yeah, it’s easy. Do this like we did on two clients.” So they just knew you’ve done it so many times. They’re just like, “Alright, we’ll send that hard fee signed over tomorrow,” and it’s like, yay! That was a five minutes sales call.
There used to be hours where I’m trying to drill down multiple teams trying to trust you and once you did two or three they didn’t care. They knew that you know what you’re doing.
CHUCK:
Yup, bigger fish, smaller barrel. Alright well, I think we’re getting close to the end of the time that we allotted for this. Anything else that we should talk about on this front before we get into picks?
JESSE:
I’m not sure I’m a guest. Whatever you gentlemen want to talk about.
CHUCK:
Anything else you want to ask, Frosty?
AARON:
No man, I’m good.
CHUCK:
Alright. Let’s go ahead and do some picks then. Aaron, do you have some picks for us?
AARON:
yeah, I’ll do two picks. I’m going to pick a book that I just recently read. It’s called Marissa Mayer and the Fight to Save Yahoo! It was super enlightening; I had no idea that Yahoo! is the company that had the most possibility to be successful and failed every single time [chuckles] and now Marissa’s trying to save it.
It was really mind boggling how many pass – how many opportunities they’ve passed up. It was insane. So I’m going to pick that book; it’s really good. It leaves you cliff hanging in the current day where Marissa’s still trying to save it but it’s really good.
The other one I’ll pick is snuggling with my kids because they’re pretty awesome and being a dad is like the coolest part of life. So yeah, those are my two picks.
CHUCK:
Awesome. I’m going to, on Lukas’s behalf, he picked Aton.io. So you can listen to me and pretend I’m Lukas but he says this editor has knocked me off my feet. It is awesome. I’ve heard great things about Atom as well so if you’re into Atom, check that out.
Another related project that you might want to check out if you’re into writing desktop apps and using JavaScript is Electron and Electron is the framework that Atom’s built on so you can go check that out as well.
I’m going to pick something very similar to what Aaron picked and that is – I guess I should tell a little story first, give it some context but ultimately, I’m going to pick having integrity even for things that seem really, really dumb and really, really unimportant. My six year old, they give them little reward cards at school and then they can take that into the assistant director’s office and then get a little reward from the assistant director. So she took her little card in and the assistant director said, “Yeah, go pick a reward,” and she grabbed the whole bag of rewards and brought them home. [Chuckles] At first we were like, “Okay, well take them back,” and so she took them back and apologized and everything and then the next day ewe figured out that she had pulled an extra one out of the bag before she’d given them back.
So I actually drove over to school, got out of the car, walked in. The assistant director used to be our neighbor so I know her really well. Worked with her on cub scouts and stuff so she knows us, she knows our kids. So we’re walking into the school and she’s standing there by the front door, holding it open and greeting students as they go in. so I looked at my daughter and I’m like, “Okay, give her the toy and tell her what you did.” It was really interesting and sometimes it’s scary but at the same time I just found that even having integrity, being honest, sticking to my values and what’s important to me pays off so much in the long run. And it’s so germane to this conversation about consulting because if you are a person of integrity, you’re clients can figure that out, your relationship goes so much more smoothly and everything just works out so much better for you. You’ll get more referrals, your relationships with your clients will be better, you’ll get paid more and it’ll all just go that much better for you so I’m definitely going to pick that.
The other thing I’m going to pick and I mentioned it at the beginning of the show is that the GitHub issues setup that I put in there, it’s based on the GitHub Ask Me Anything that you see around there. But if you have a topic or suggestion for us, something you want us to talks about then go in there and put it in, make a suggestion. You can suggest guests or topics or both so feel free to jump in there and let us know what you would like to hear about.
Finally, I have been talking to a lot of people who listen to the shows and I would like to talk to you. If you’re new, I don’t care; if you’re old, I don’t care; if you’ve been doing this for a while, I don’t care. I want to talks to you anyway. Go to adventuresinangualar.com/15minutes and pick a time on my schedule and we’ll do a Skype call for 15 minutes. I’ve done this with a whole bunch of people, I talked to a whole bunch of newbies, I’ve talked to a whole bunch of people who are transitioning from one technology to another, who are starting their own companies, who want to start freelancing, who want to start a podcast – you name it, I’ve probably talked to them about it and I am just loving having these conversations with people.
So if you think that I wouldn’t want to talk to you, you’re probably especially the person I want to talk to so go and sign up for that.
Jesse, what are your picks?
CHUCK:
Really three. I’ve got two blog posts that I use for 1% of my research. They talk about the DevOps from the NASA days of launching rockets and the ones that went wrong so the European Ariane 5 and 4 as well as the Mars Global Orbiter and some of the reasons to why they failed. Those are my first two. I use this as a gateway to learn more about how NASA does DevOps and testing and things like that both back in the ’90s as well as today.
My third pick is basically Jspm.io. I don’t know if anybody’s talking about Jspm at all but it’s been something I’ve been looking at for trying to create what we have to recommend is a DevOps cornerstone for Angular 2.
And so I’ve been falling in love with all the libraries that make it up like ES6 module loader and SystemJS. So definitely Jspm.io and all the CLI tools that go with it.
CHUCK:
Yeah. We had a conversation with Scott Allen about package management in angular apps. So we talked about Jspm and Webpack and a few others so definitely go check that out if you’re interested in this stuff because there were a lot of discussions about what the tradeoffs are and why you might want to use one of the other.
JESSE:
Cool.
CHUCK:
Alright. Thanks for coming Jesse. If people want to find out what you’re working on or follow you on Twitter or have a conversation with you, what should they do?
JESSE:
My blog is jessewarden.com/blog and my Twitter handle is @jesterxl.
CHUCK:
Alright, well thank you again for coming and we’ll wrap this up and we’ll catch everyone next week.
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]