Jason Johnson gives us a great presentation on the “care and feeding of a developer”. Be sure to follow him on twitter: @jason_johnson.

You can watch the video above or read the full transcript below, the video is much better but sometimes words are nice too:

Jason Johnson: Before I even introduce myself, how many of you work with developers every day? Almost everybody. How many of you are actually developers? I know there’s at least one. Got a couple back there. You’ll sympathize. What’s that? That corner? OK. Maybe I should be sitting back there. But you’ll sympathize with a lot of this.

All developers are not created equal. They’re not all the same. A lot of us are hackers. A lot of us explore a lot of different technologies. A lot of us specialize in one thing. And a lot of us are nice guys. We’re all nice guys. But some of us are kind of jerks, hard to deal with. But there are reasons for that. I promise.

Seriously, though. Who is this guy? Who am I? Why am I talking about this? Why am I an authority on this subject? Why does anyone care what I have to say?

My name is Jason Johnson. I’m from Dallas, Texas. I’m actually from Greenville, but I live in Dallas, Texas. I’ve come here because I work for Gene. I work with Period Three. And I’ve actually worked with Gene since I was 17 years old, so he and I have a very lengthy relationship.

This is Jason. This is the Jason that Gene talks about all the time. I hope it’s all good. I am a developer. I build software, and I have built just about all the software that Period Three uses. We host almost 300 Websites. All of them run my software. A lot of the special products that we build, I’ve built and have maintained for years.

A little bit more than that, I’m a really good developer. That doesn’t mean… I can’t hack better than these guys, anymore than they can hack better than I can. We’re all probably pretty good at that. But to clarify, I’m a good citizen, a good corporate citizen. The relationship that I’ve built with the guys at Period Three has helped all of us grow a lot better, I think, in our products, in our game, the stuff that we do for clients all the time. We communicate very well. The limitations that I have are known by all these guys, and it works pretty well.

I was the original employee of Period Three. I was employee number one. That was many years ago. Seven, I think. About seven years ago, I was employee number one, started in my bedroom on a plastic table with a 17 inch monitor. Not kidding.

But I took a two year hiatus. I thought that the grass was greener. I thought somewhere else would be better; I could work on some big stuff. It turns out, I found some big stuff.

These are people who I’ve done work for. It’s Fortune 500 companies, right? Fortune One and Fortune Five companies. The stuff that I’ve built for Wal-Mart, my software is literally in every single store in the country. Every Wal-Mart store manager uses my software every single day. Every sign that you’ve seen in any Wal-Mart has been ordered through the stuff that I’ve built.

Dick’s Sporting Goods, I did dynamic imposition of PDFs, which was incredibly complex, and it blew my mind, because I didn’t know anything about the print world, and a lot of the stuff that I did for these people was for print. So I had to deal with a lot of designers, and a lot of designers would yell at me on a daily basis, because I wasn’t doing things right.

But there are two takeaways from this, away from the experiences that I had. And if you don’t know United Stationers, literally every office product that you’ve used in your life, they’ve made. They sell all their products to Office Depot and stores like that.

But the two takeaways. One, all these people use Excel. Everyone uses Excel. These mission-critical systems and everything, you boil it down, you uncover stuff, and at the bottom of the pile there’s going to be an Excel spreadsheet that looks like crap. There’s going to be terrible formatting, and it’s going to make my life, and these three guys back here, their lives horrible. But that’s for a totally different presentation.

The second takeaway from working with all those people, with all those companies, is I quit. I hated it. There are reasons for that. But what was great is that it trained me. It trained me how to deal with really, really difficult situations, difficult clients, and also difficult employers. My employer was extremely demanding. Overnight trips or same-day trips to Bentonville, to Pittsburgh, to New York, to California, same day. Get on a plane, go talk to these people: “Something broke. We don’t know what.”

Why did I quit, though? Three reasons: I was unchallenged, I was unfocused, and I was unhappy. These are the things that make your developers angry at you. Challenged is not really what you might take it to be. Challenged in the sense that- we all come across challenges. Databases are sometimes unwieldy. They’re difficult. But technical challenge is not what I’m talking about. I’ll get to that in a second.

Unfocused. My managers didn’t understand that that really enormous, big, critical thing couldn’t really be done first because I wasn’t pumped up enough for it. I wasn’t ready for it. It hadn’t gelled in my mind yet, or in my sketchbook, for that matter.

Unhappy. That’s a tough one. When I was building these pieces of software, when I was building all these systems, they had me working on terrible, terrible equipment and things like that. But I’ll get to that.

First, challenge. There are all sorts of ways you can challenge your developer, and it turns into motivation or whatever, whatever you’re looking for. The phrase that any developer, they’ll seethe at, is this one: “It can’t be done.” This is trite. It’s terrible. You don’t want to be saying this to any of your developers, because it’s sort of an insult. It doesn’t bring them into the process. You’re challenging their ego. Their ego isn’t exactly what you need to be challenging. So that’s bad. Don’t do that.

“How can it be done? Talk to me about what you’re thinking” is what you should be talking to your developer about. This addresses what people mistake for… Well, here. It’s pride, not ego. Yeah. All of us, all three of us, we’re all guilty. Me, I’m especially guilty. I have an enormous ego. These guys probably have a pretty healthy ego. That’s not really what drives us.

We want our managers and our clients to appreciate us and to have pride in what we do for them. So pride is much more important than this ego. We have a huge ego, but I’ll show you how to address the pride instead. Opinion. Developers, believe it or not, have some great advice in terms of business and strategy and design. Oh my goodness, we do actually design stuff every day. And we use incredibly creative processes to get to the point where we can build the things that we do. So ask and ask often, ask all the time.

Well, let them write code and stuff, but ask as often as you can. Also, it’s really good to push your developers to where they’re uncomfortable, not to where they don’t like you. If they still do. Or if they’re working with the same technology all day, every day, they’re not uncomfortable. They get lazy, they get complacent.

And any good developer is actually a pretty lazy developer. We like being lazy, we like automating things. So challenge them, make them uncomfortable. Introduce a problem that’s very difficult to solve, but let them work on it a little bit. Also, a great way to challenge your developer is have them show off what they’ve built. Don’t take it with you on a laptop and say, “I’m going to go show these clients. I’m going to go show them everything that you did.”

That just destroys their pride. They’re glad that you love what you built for them, but they’d like to come show it off, too. They want to get some credit, they want to feed that pride. But more importantly, it’s necessarily the ego that gets fed here, it’s their pride. Also the tell part, let the developer talk in front of your clients. It’s great and you might hear some stuff that you never expect. And most of the time it’s pretty good. Anyway, it’s pretty ambiguous. But focus, this is pretty important.

Getting a developer to focus on stuff. This is what a lot of designers… Designers can open a sketch book and just start going to town. And it could be crap, could be great, whatever. They can begin immediately, but focus is a process and design is a process too. But in development, it’s a really, really tiring process. Getting focused on a new project that we might not have complete information about. We might not know enough about the client to know where they’re really going with the system you’ve asked them to build.

And it might appear to all of you managers, designers, whatever, that it’s procrastination. That we’re really sinking into whatever bad habits that we have. When truly, it’s incubation. These ideas have to fester, they have to grow in our minds for us to… Well, here, it does look like an awful lot of procrastination.

But the way to fight this, there’s a very, very specific way to fight this, is that you have to be able to find some way to build momentum. And the best way to build momentum, even in the smallest quantities is to start with the smallest thing first. The tiniest aspect of a project that will actually get you a half of a step closer to your goal. If it’s creating some entry in Apache or if it’s just creating the database or creating the layout or sketching some idea. Whatever it is, make it a to do item, and make it as small as possible.

And get your foot in the door with that project. So smallest first. Now here’s the kicker, is that you hope that your developer is working all day. You really, really hope that he’s doing something with his time instead of just reading Digg or Reddit or whatever.

This is tough for a lot of people to swallow is that 30 minutes is a lot better than zero minutes every day. We might spend upwards of six hours a day just spinning our wheels and it frustrates equally as much as it frustrates you. Because we want you to be proud of us. 30 minutes of hacking a day is awesome. That is, it could be a lightening session, something just clicked and we get 30 minutes of just unbelievable code written. It’s beautiful, commented, everything. Oh my God, that’s an amazing day. If it’s an hour, if it’s two hours, that’s just legendary.

But here’s something else, is that if you think of it in these terms, if you think of the smallest first and these tiny little tidbits of things getting done first and building momentum. Is that if you break down these tiny pieces, you going to client, showing stuff, whatever if you’ve managed developers. This is great. If you put those tiny things first, you get to go to a client and say we’ve got these 15 things done. 15 is such a huge number compared to one.

You get to say we did this one big thing, but we’ve got these 15 things ahead of us. That’s why you always want to start with that smallest thing first, because that number starts growing very rapidly. Just today we had a meeting where I had two things left to be done. They were huge and they were monumental.

But we had done eight things prior to that. We left the big things for the end and we built so much good will with the client that they were like, “take all the time you need. You know, get those two things done as quick as you can, but no pressure. You just kicked ass for us, you just did eight things for us.” Now, to keep your developer happy, which is important to focus and all that other stuff. This is pretty critical. Like, I don’t know where my phone is, but I have a first generation beat all to hell iPhone that barely works. I can barely make phone calls on it because I don’t care. I don’t care about my iPhone.

That’s terrible to say. But the point is, you’re not gadgets. If you have any authority or any input with your managers to hook up your developers in any way, you want to go for the gear. Now what do I mean by that? Passive items, not active. Don’t buy them trinkets, don’t buy them an iPod as a Christmas present. Don’t buy them an iPhone or buy them some throwaway consumable thing. Buy them a larger monitor, a second monitor, something that’s passively helping them do their job.

They’ll be far happier with something that does that. I’ll be far happier using a 24 inch monitor than a 19 inch monitor for the rest of the year. You won’t see me coming to work with a grand smile on my face or something but I promise you it will work over time.

Now another thing that keeps developers happy, this is also why a lot of developers that you come across are also musicians or have some other interest that involves this. I don’t know if any of you guys in the past have played an instrument or anything. I see someone saying yes and someone saying also yes. And yes.

OK, three of them have some sort of interest in music, and you all listen to music while you hack? Right? Yes, there’s a connection here – patterns. Developers love, love, love patterns. Oh my God do we love patterns. We like relational databases, we like constructs and languages that do really neat things and they happen over and over again. So we’re constantly looking for these patterns to satisfy this need for immediate gratification. We love it.

Now, what is a pattern? What is a pattern to a developer? Well these are patterns to a developer. They’re really simple patterns, but these are all the same program. Each line is a different program, not an entire program but most of one to get the idea.

But, these are patterns but they’re different ones. There are different flavors of patterns that we go after. There is some C# there, there is C++, there is some Ruby, and I think that’s Haskell.

Lots of different programming languages, lots of stuff to explore as a developer but then there’s this stuff. This is crazy. I’ll not going to repeat the name of this language, but it’s terrible, but it’s also really fun. This actually makes sense to a programmer who understands pointers. Who understands memory addresses. You’re moving memory around at the lowest level possible.

That’s really fun but literally what all these programs, which it is pretty obvious what they’re going to do, what this does is all it does is print this out. But, the reason why that’s fun is because of the patterns, all those different flavors.

Now you might say in response to the dozen or so programming languages that I’m sampling here, there are 400 some odd known programming languages that are not some guy’s college experiment.

But, we use .Net. Why do we care about all these other patterns and all these other technologies that my developers might be interested in?

There’s a very simple explanation for that. Is that this, if we use .Net…we can use PHP, Python, Java whatever we need to get the job done. But, if we use .Net, everything else is better than .Net to us, everything. If it’s Ruby, if it’s Python, everything else is sexier than .Net. .Net is what we do all day. We hack on .Net everyday whenever we do Java, PHP, whatever.

But, this is something you honestly need to explore with the developers that you use all the time or whatever. Ask them about new technologies. Let them hack on other technologies even if it doesn’t mean that stuff’s getting done, it means that they’re happy and they’ll find focus, find patterns and bring them back to your projects.

So, that’s it. You guys have any questions? Oh really that’s it. But…you have a question go ahead.

Audience Member 1: Just a statement. I’ve got a lot of friends who are non-developers, semi developer, and what I have explained to him which he says makes it easy for him to cope with the many different developers is by telling the best developer is normally autistic. To a certain extent we can’t help ourselves, and we all have our tics.

Jason: Oh sure.

Audience Member 1: That helps India with those it just makes it easier. When you walk into it knowing this guy is looking for patterns from what I am talking about, this guy is looking to get the information I am conveying to him. You learn to take your time, be patient, and explain what you are talking about.

Jason: Right, that’s true. Every developer does have their own set of quirks. I’m sure we can all relate. I’m sure my guys can relate too. I have my set that are interesting. Any other questions for me, about me whatever? I hope you enjoyed it. That’s it.

Audience Member 2: I have a comment.

What my take away is from your conversation is whether you’re a client, a designer, or a developer there is a creative process that goes on and I can relate as a designer to your process because there are a lot of the same issues that a designer has that goes through a process especially the procrastination, the hibernation, whatever you want to call it. So I guess that’s my take away that it is relatable and just because you’re a developer you’re still creative, you’re still creating.

Jason: The level of creativity that is required to develop things and especially new systems and that’s why I said not every developer is created equal. Because they are not.

Someone who can hack on WordPress and customize WordPress isn’t the same guy who could build WordPress from the ground up or any kind of system you are talking about, any guy who can patch your system is not the same guy that can build one from the ground up.

That’s where when you get really deep into it; the level of creativity is astounding. You look at guys who build entire operating systems. That it’s not by accident. They had to invent this stuff. They had to create it. They had to get creative in how to manage memory and how to manage data. It’s not easy. It’s not straightforward. These are problems to be solved just like a user interface problem is a problem to be solved by way of creativity.

Everything that we saw that Gene and Jay and all these guys showed us was a process that involved creativity and this is really no different. It uses the other side of the brain, but it is still problem solving in very much the same way.