Dan Draper, Developer + Entrepreneur: Inner Life Tips for Coders

Dan Draper, Developer + Entrepreneur: Inner Life Tips for Coders

How to evolve long-term — what REALLY makes a great programmer, personally and professionally

Dan Draper has traveled through several tech startup journeys, enjoying the highs and enduring the epic lows of being an entrepreneur. Having learned to code at an early age, he's reaped over 20 years of coding experience. His decision to become a technology communicator now helps inspire the next generation of coders.

Dan’s current work includes building Codehire, a new way to connect coders and companies, a web channel for new coders, and his role as the Executive Producer for a new documentary on gender inclusion in the tech sector.

In this Codecast, Dan breaks down life-enhancing insights gained throughout his career, and shares practical tips for success as a programming student and professional developer.

Key Theme » Empathy

"A great coder is not someone that can write an entire Ruby app on a weekend. A great coder is not someone that can improve your database query speed from 500 milliseconds to 10 milliseconds. Sure there's elements of those technical skills that you always look out for — but a great coder is someone that can work well on the team, can ask questions, can help their fellow team members. Can show empathy for the other members in their group, is willing to keep learning, and is willing to accept that not everybody necessarily understands things as well as they do, perhaps. Accepting that you may know something that somebody else doesn't — and vice-versa — that they may know something that you don’t, is a really important part of that process...I think we can learn from everybody." — Dan Draper

The Codecast

Watch on YouTube

Full Episode » Transcribed


Welcome everyone and welcome Dan! Thanks a lot for joining us. This is the Viking Codecast, a service to all of our students and anyone else who’s interested in learning how to code. We bring in professional developers, and have them talk to us, providing wisdom hard-won over their years to make it a little bit easier on the path for you.

Dan I'd be grateful if you could describe who you are and what’s gotten you to where you are today?


Absolutely! First thanks so much for having me. I’m really passionate about talking about technology and code, particularly with people just starting out on their journey. I think there’s a big challenge globally right now where the world doesn’t have enough coders, and that’s not a problem we’re gonna to solve anytime soon. So, it's inspiring to see people decide to pursue it as a career or who, at the very least, add it as a tool to their toolkit. I think it can be very empowering to know how to code.

My personal background, I’ve been coding for over 20 years now, not all of that professionally. About 14 or 15 years, professionally. I started coding as a teenager and...this is kind of hard to imagine now, but when I started coding there was no internet access. So, I didn’t have internet connectivity at home! I had an old MS DOS computer and I learned how to program using an old language called QBasic. Anyone who’s over 30 may know that, but if you’re not over 30, you probably haven’t heard of it.

It was kind of Microsoft’s first, consumer coding language back in the day and I learned how to code from “help” files, believe it or not. Lacking internet access and lacking any kind of resources, it was very, very difficult. Somehow I managed to become semi-competent and I really enjoyed making games and little, kind of graphical apps, music apps and things like that — super-super simple compared to what we can do now!

I finished school, went ahead and studied electronic engineering here in Australia, at a university called the University of Adelaide which is quite a good institution here. As much as I loved electronics, I was continuously brought back to this idea of software engineering. So, I ended up getting a job before I graduated! Which, is a double-edged sword right? I was, as a student, living from week-to-week on beans and toast. I wanted something a bit more fruitful in terms of a salary, so I jumped at the opportunity when I was offered a job. I had every intention of going back and completing my studies, I never did. But, back in those days there was nothing like Viking, so it was college or nothing, right?

I got this job and a few years in I had this crazy idea that I wanted to do a startup. And so, a friend of mine and I got together and we created a company called NetFox which was essentially a tool to help get better internet access in high schools. This was kind of the first few years of [...] internet cell connectivity activity in Australia. We did pretty well with that business, actually, for a while. We built a team, we built a really interesting technology, we raised some money, built it to around 300 schools in our jurisdiction. But we, being young entrepreneurs, got distracted and we didn't keep it together. We lost focus and ultimately the business failed.

But it was a huge lesson for me. I see my experience doing a startup as way more valuable than anything I learned in school. All the things I learned in school were really important and they set the foundations, but those lessons in a startup and learning some of the technical challenges and people challenges and marketing challenges, and all the rest of it was super valuable to me.

Despite the fact it failed, we went out together, my business partner and I, and we did another one — another startup. And this time, it was a little lower risk, it was a software development agency. We started building applications using Ruby, Ruby on Rails, in particular. Sort of in the dawn of the Ruby era, back in about 2008. And we started working with all sorts of different companies, in some of the big cities in Australia. That business, thankfully was much more successful and we exited that in 2012. Once again, that took my understanding of the technology industry and how technology and code relate to people and real-world problems — it took that understanding to a whole new level.

Since then, I’ve been taking a variety of whole different roles. I was the Chief Technology Officer (CTO) for a digital marketing company, here in Australia and then I actually spent some time in New York. I was the CTO at an airline startup, based in Manhattan. That was a challenging but very exciting business to be a part of. Now, I’m back in Australia, based in Sydney, and I’m consulting — about as far away as you can get from a startup. I’m consulting for the Australian Federal Government!


Which is a whole new set of challenges, but it’s actually really interesting to see how different how people’s perspectives on technology are in a startup, in a customer of a startup, versus a public servant working for a government.

Never limit yourself, as a coder or professional.

And, I think one of the pieces of advice I give to people wanting to learn to code is don’t put yourself into one kind of silo. Make sure you go out and try different roles. The great thing about being a coder in this modern era is that there are plenty of opportunities for you in lots of different walks of life. I think you become more rounded as a person, more rounded as developer when you try different things, you try different industries, you work with different teams, you work with different philosophical outlooks on how technology should be used. I think you become a much better person, in general.

I feel like I’ve grown, I probably still have a lot more growing to do but it’s been an exciting journey, so far.


That sounds fantastic, I’m loaded up with questions (laughter) to ask you.

One of the things that occurred to me when you were describing learning in the early phases is that nowadays we have an entirely different set of tools for teaching coding and for learning how to code.

As someone who’s worked with a number of developers over the years and hired developers over the years, I’m curious if there are some hard-won lessons that you got from the experience of having to learn from manuals, and having to learn without the benefit of Stack Overflow, or without the internet, or without interactive, Codecademy-style tutorials that taught you things that these days aren’t such common sense anymore?


Yeah, certainly. What’s interesting, when I first learned to code when I was a teenager back in the mid-90’s — and things were very different there, like you said, I didn’t have internet access — I don’t feel like I’ve ever really stopped learning.

I learned Basic as my first language, then next was this obscure language called Ada, and then I learned Java, C, C++, C# / Sharp, then of course, Ruby, JavaScript and number of others along the way.

And, every time you came across a new language, the process gets a little easier. What you find is you become better at learning. The more you practice something, the better you get at it.

And where I think a lot of developers go wrong, is they kind of learn a language, let's say it’s Ruby, and they say “ yes, I can code! I know Ruby now”, and they just sit on that, and maybe they get really good at Ruby and become like an expert in that domain, but then they forget how to learn new stuff. And, if that goes on for too long, it can be really hard to break out of that. What happens in 10, 15 years time when Ruby is no longer the language that everybody’s using? By the way, Ruby it’s a great language to learn and probably will be for a while, but further down the track, there’s gonna be something else.

If you don’t continue to learn, embrace new technologies and try new things out, I think you can fall behind really, really quickly — and it will probably happen, without you realizing it.

The other thing I would say is that when you’re learning something, rather than just taking the academic approach and going “I just want to learn x, y and z, I know I want to try to get through this book or this manual…”, rather than doing that — pick something specific that you actually wanna build. So, I wanna build this thing — whether it’s a game or an app, or a website or a blog. Whatever the case may be.

Pick something that you want to build. Then focus your learning around finding the things that allow you to build that thing. Then you’ll find that because you have purpose in your learning, you’ll find that you’ll retain information much better.

Also, whenever you get stuck, whenever you feel like you’re falling off track or you're not quite sure where the next steps are, you can always go back to, “what is it I’m actually trying to build? What's the next step in building that thing?” It really helps you focus your learning and become a better coder in the process.


No, I absolutely agree that learning by building is the most powerful force that I've found personally in my own learning and that we’ve found with our students, as well. It’s something that you can’t hear enough. It’s sort of commonly offered, but rarely taken advice, (laughter) because one of the common refrains is typically, “I don’t know what to build, how do I figure out what I'm supposed to build?”

It sounded like you just went out and built a startup!


Yeah, see that’s the interesting thing about being an entrepreneur is that actually, in many ways, the code came second. So I had this idea, and wanted to do this idea. At that time I had some level of coding experience, but not a great deal. And, I needed to work out how to build this thing. So, the coding almost came secondary to what I wanted to achieve.

Have a purpose for your coding studies.

I think that’s where a lot of coders probably go wrong, they’re not clear on what their purpose is, what do they actually want do, want to achieve? Who do they want to work for, what kind of apps do they want to build?

Kind of get that in your mind right first, and then the learning, although it will still be challenging — learning to code is not easy — it will be much more straightforward, once you know which path you wanna go down.


Oh, totally. So, there’s always a choice after you’ve gotten to the point where you’re employable as a software engineer, in terms of asking, “what am I gonna do next? Am I gonna join a big company, a consultancy, a startup, or am I gonna start a startup, or am I just gonna freelance?” There's this whole range of options and again, you’ve obviously taken one of those and no doubt, seen people throughout your career who’ve taken other paths.

I’m curious if you have any advice around the right factors to optimize for, when students are making that decision around what should that first or second step be — after building up a reasonably valuable skillset?


Yeah, absolutely. There’s a few things to talk about. It does depends largely on what kind of person you are and how big a risk you want to take. And, also how motivated you are. The thing that I say to most developers when they’re first starting out, is find a big enough team that has the time and the resources to mentor you — and to guide you. One of the big challenges is — how big is the Viking course, 16 weeks, right? Yeah, 16 weeks, I mean that might seem like a long time and I know you folks are about halfway through that now. It probably feels like a long time until you’re going complete — ‘cause you’re working so hard and you’re absorbing so much information. But, 16 weeks is not all that much time. And, as amazing as I’m sure Viking Code School is, once you graduate there’s only so much that you gonna have ingrained into your abilities and knowledge.

You really have to keep learning, you have to keep surrounding yourself with people from whom you can learn. Going into a team that has the bandwidth to provide that assistance for you is really important.

That said, it's not strictly required. If you wanted to go and start your own business, or start a startup, or join a small team, that’s absolutely do-able. What you have to remember in that situation though, is that you need to prepare to put in extra hours of work. You need to go and look at screencasts online, or maybe try committing to an open source project and find some mentors in the open source community. Or, get onboard with some meetups — there’s plenty of Ruby and JavaScript meetups in every major city in the world — and find some mentors and compatriots, in that regard. I think that’s hugely advantageous.


So, definitely optimizing for learning is something we talk quite a bit about, when we’re having career discussions. I am pretty interested, specifically, in the difference between joining a team and — one thing you mentioned was come with a project and work backwards and essentially do what it takes to build that project. But, then the far extension of that, is that the project itself a company. Working on a project and learning up to a project is almost like a bit-sized version of the eventual, “I'm gonna go out and build a company.” But, a lot of what you hear from people who have had to be self-taught, to the degree that they’ve had to level themselves up while learning about companies, is that they feel like there are a number of gaps in their skill sets versus if they’ve joined a team.

I’m interested in your perspective on what that transition point looks like from “I’m going to build stuff on my own” or “use a project as a guidance for my learning” to “I’m going to step onto a team and let them help push me up.” What is the appropriate balance between those two factors?


Yeah, I understand. I don’t know if there's an “appropriate balance” necessarily, everybody’s different. But, I think I can share my own experiences and those experiences may help others along their journey.

I actually don’t think my experience was the best example. The reason I say that is because I only really worked for about 18 months, after I left college, before I decided to make a startup. One thing, I didn't realize this at the time, but I didn’t have very strong mentorship when I was working in the corporate world. And, I went into my startup pretty blind. Of course, at that young age and with that much enthusiasm I probably didn't think I was blind at all, I probably had so much confidence and belief in my abilities that nothing could stop me. That’s an amazing thing — don’t get me wrong!

But, I think if I had my time again, I would’ve spent a couple more years in the tech space. I would have probably changed companies and moved to a company that was able to provide me with that mentorship and learning, and try to understand a bit more about how tech works in teams. How you negotiate with customers, or stakeholders, and how you elicit user requirements. A whole bunch of really important stuff around Agile and SCRUM. None of that stuff I knew from the beginning, and it took me quite a while to work it out.

There’s nothing to say that you folks, or students won’t work that stuff out, but I think there's a lot of value in working just a couple of more years for a bigger company, and trying to accelerate that learning a bit. I think that’s probably my recommendation, if you can do that. Doesn’t mean that’s going to be the only way, but it’s probably going to be the best way, in many cases.


So, anyone have any questions?

Otherwise, one thing we were hoping to focus on today was some semblance of the softer skills needed to be a developer. We spend a lot of time talking about code, a lot of time talking about hard skills. But, at the end of the day, as a breathing functioning human you’ve obviously got a whole lot of other things going on and you’re just optimizing for learning code all day, you’re gonna crash and burn.

In particular, you’ve clearly lived a number of different iterations of your career through some pretty crazy environments. I’m curious to hear your thoughts around how to keep yourself whole, balanced and moving forward when the macro-factors are all lined against you.


Yeah, certainly. So, I have lots of stories to share, but let me start with my first story. I remember in my first startup, we actually had a very early-stage release out, some customers were using it and it was working reasonably well. But, they’d been screaming at us for new features and we knew had to release a new version.

So, my business partner, he was kind of the sales guy, he set up an event where we were going to launch this product. We thought this was a great idea! You know, being a confident young man I thought “well, I can smash this out on no time, this going to be straightforward.” So we put a fairly ambitious date on the launch and lots of companies were excited about it, we had quite a big turn out and it was turning out to be quite a big thing, right?

One week to go before the launch, I realized just how much work I had to do. I had one other developer working for me at that time and he got sick. Like a really, really bad flu! So, here I was on my own — and we were talking about RedBull before (the Codecast) — and I don’t actually drink RedBull anymore. But, this week I drank gallons of RedBull, and I actually did over a 100-hour week that week — which I don’t recommend, maybe if you’re a student you’ve done 100-hour weeks before.

We actually got the product done, we got it out. On the Sunday afternoon prior to the launch, the launch was Monday morning, on the Sunday late evening I actually said to my business partner “can you take me home? ‘Cause I can’t drive. I can’t even see one foot in front of my face.” I was utterly exhausted. It took me two weeks to fully recover from that.

Your health matters — dropping the "hero coder" syndrome.

What I learned throughout that process was that sustainability is actually way more important than just output. You can have this huge spike in output, but generally-speaking, what comes up must come down. I’ve seen this pattern repeated over and over. And it’s a very easy pattern to fall into.

I think where a lot of developers get it wrong, is they get into what I call the “hero coder” syndrome. So a hero coder is someone, maybe she’s got a particularly difficult problem to solve, and maybe she’s got stuck along the way. But for whatever reason, the solution isn’t quite getting there but, she just doesn’t want to give up.

You kind of get up to this barrier where you’re not making any progress, but you don’t want to give up either, so end up spending 18-20 hours one stint and it can be incredibly frustrating. I would hazard to guess that those of you that are learning to code would probably understand this. It can be incredibly frustrating.

Here’s the most important piece of advice I can give you — which sounds utterly counter-intuitive and can be quite hard to do, you have to be very disciplined. The best thing to do in that situation is get up and walk away from the computer. And stay away from the computer for awhile, if you can.

Go for a walk, see some friends, go out to dinner. Do whatever you gotta do. And, 9 times of out of 10 when I do that, I’ll be away from my computer for a couple of hours and then all of sudden something will pop into my head, and I’ll have the solution. Then I can rush back, and all of the sudden I’ve solved the problem. So I think, that’s probably a really important thing. So, sustainability. And don’t force yourself to stay in from of the computer, walk away.


Yeah, I think one thing that we do talk about a reasonable amount is having a meta-awareness of yourself, we talk about it in terms of the learning process on one end, but there’s also the kind of the coding and work side of things, too. I mean, the way that we talk about it is in terms of understanding your sleep patterns, understanding when you are a little bit more creative. When are you are a little bit active? But, also when are you starting to burn down? I think having that awareness, both on a short-term basis and a long-term basis, is really important.

You can bang out some pretty amazing stuff in a pretty short period of time if you’re caffeine-fueled, you have the momentum and you’re ready to go with it. But there is definitely a point, even on an individual, day basis — I can’t speak for anyone else, but I can speak for myself — that I will certainly get to a point where I sort of have gone from reason to obsession.

And, there's this fine line between being motivated and being obsessed! This will happen late at night or early in the morning, after a really, really long session, when there’s some problem that just isn’t solving itself. And, you know you just kind of ending up banging and banging and banging. And you have to get to end. It’s a lack of meta-awareness, where actually, sometimes when you finally get to the point 4 hours too late, that you should’ve actually stopped and gone to bed — you’re waking up in the morning and realizing — 9 times out of 10, you just throw away everything you wrote the last night anyway!



That‘s right! It’s a tough balance to strike, sometimes, because I find what happens is, if I force myself to walk away — and, let’s say I just go to bed and try and get some sleep — sometimes, I’ll lay in bed thinking about the problem and then I won’t get any sleep.

So even though, you know going to bed and getting some sleep might be the best solution for you, sometimes it’s pretty challenging. So, in those cases, I’ll usually just go and do something just totally unrelated to technology — even though it’s late and I should be sleeping — I’ll watch a movie, or play a game of cards or something, whatever can take your mind off of it.

Actually, while I think of it, there’s another thing I should mention. This is not something I learned until much later in my career. It’s actually not just — I like the way you talk about meta-awareness — I think that’s really important.

But, it’s also what’s the awareness and understanding of the people who are close to you? So, if you’ve got a partner, a girlfriend or boyfriend, or your family or friends, they kind of need to have some sort of empathy for what it is you’re doing. If they’re not a coder, they may struggle to understand why you need some quiet space and why you need to lock in, and just not engage in conversation for a couple of hours while you try to work on some code.

I find that just sitting them down and explaining to them what it is I’m doing and kind of coaching them on what it is I do, and setting up times of the day where I don’t get any interruption and they know — “OK, Dan’s working, let’s just leave him alone to do his thing” — that can be hugely valuable, as well. It makes for happier relationships. When you’re in the middle of a problem, and somebody interrupts you and you get upset because you lost your train of thought, or whatever...it’s another interesting life skill, I think.


Oh, absolutely. I think there’s been a lot of interesting research, as well, around the idea of “maker” schedules and “manager” schedules, and the need for people like developers to really get long and uninterrupted stretches of time. You get into a flow, you get into a momentum, and then one interruption and then all of a sudden the wave comes in and washes away your sand castle, (laughter) and you have to to start all over again!

I think there is a really important point — especially if you work in a mixed workplace (or in a mixed home!) — that you do end up educating the people around you. Specifically again, like in the workplace, this might end up being your manager. This might end up being your product manager, or people on the sales team, or anyone in your open office plan (which developers absolutely hate). That it’s kind of like, “headphones on means: I need to be uninterrupted, focused.”

One thing that I’ve noticed a lot of, is you really need to fight for your ability to produce. Just by being quiet, and assuming that people know what you’re going through is not always — rarely — the best way of going through things like that.


Yeah, I totally agree with that.

I’ve just noticed that [Sia / Student] mentioned, I think, “...the research basically says that, ‘similar to endurance cross-training, you need recovery time for your brain to recover and find your connections.’ “

I totally agree with that. You know, anecdotally, I feel that definitely applies to me. If I push myself for too long, not only does it take a long time to recover and feel motivated again, but I can’t concentrate as well. I find that I’m not able to solve problems as easily. So, image if you tried to run for 8 or 10 or 15 hours a day, every day, your running would be appalling by the end of it, I’m sure.

That’s a great point, Sia, thank you!


Yeah, I'd actually like to open it up again. You guys feel free to ask questions.


I do have a quick question, actually. Looking at where the industry’s moving, considering it’s always changing, you were talking earlier how it’s a good idea to always be learning new languages — rather than letting yourself be pigeon-holed, to a single language.

How do you feel about — rather than finding that single, big corporation as your first job — something like contract work or something that doesn’t tie you down.

Is it more dangerous to do something like that, straight out of school?

Or, is it a good idea — because it kind of forces you into something new, as soon as your first contract is up?


That’s a really interesting question. So, once again, I preface this by saying that not every — this advice doesn’t apply to everybody, not everybody has to fit this mould.

But, I would say that generally speaking, to go into a contract role very early in your career, will be pretty challenging. Especially if you are — unless you’re going through like an agency and that agency has other developers, product managers, or whatever to support you — if you’re dealing with directly with a client, I think that can be incredibly challenging. Even if you are really experienced — that can be very challenging work.

It can be very rewarding — you know, the whole idea of being a digital nomad, and going to Bermuda and working for a month in Bermuda for a month for some client somewhere in New York — that’s such a cool idea! But, that reality is that a lot of customers, especially if they are not very technical themselves, have very, very high expectations of what a contract developer is going to be able to do.

And, you really do need a decent amount of experience to navigate some of those challenges. Because you’ve not only got very, very high expectations on the technical side, these customers will often expect you to know probably way more than anybody that’s been working in the industry for a couple of years, knows.

But, the other challenge, of course is that you have all these other issues like: making sure they pay you on time, making sure that you understand the scope of the project. Are you gonna work in an agile fashion, are you gonna fall back to the old “waterfall” style?

And, a lot of customers if they’ve not been exposed to technology before will try to get you to commit to a specific scope, for a specific fee in a specific time frame. And, that’s generally, pretty much impossible to achieve. Of those three things that you’re working on — scope, cost and time frame — usually, you can only meet two of them.

That means, in some cases, you have to negotiate with your client to understand what it is you’re going to be building (scope), how long it’s gonna take (time frame), and what are my costs. And that’s something that takes some experience to be able to do, as well.

So there’s all these additional “meta-skills” when you start going out and contracting on your own. And, I think the really important thing to think about contracting on your own, comes back to what I said before: it’s really difficult to get a support network. You really have to go an extra mile to find people in the community or people online to help support you, if you need with anything — and that can be much more difficult. So, like I said. That’s not necessarily advice for everybody, but I think it can be pretty challenging to be a sole contractor, right out of the gate.


That's a good question.


Yeah, great question.


I have a question.

So, I see that you’re working on a diversity documentary. Do you have any advice for new developers — really of any culture or gender to make sure they don’t exit earlier — basically give up because of either diversity/gender issues or just poor work culture issues?


Wow, that’s a big question and it’s a really tough one to answer. I’ve been — so, just for everyone else’s benefit, the documentary that Sia’s referring to is a documentary I’m working on with other folks called “Debugging Diversity.”

It's a topic I’ve been working on for a couple of years. And it might seem a little strange that a white male is working on a project about diversity. But, what I've realized is that the vast majority of the industry, at the moment sadly, is made up of white male software developers. And, while that's not ideal, it’s definitely a challenge, I think for the most part people working in the industry wanna do the right thing. They have really good intentions. I just think that very often they don’t realize that their own company biases, or their own behavior can have a very detrimental effect on other members in the organization.

So, to come to your question, as hard as it can be sometimes -- when you're entering your organization and perhaps you do come up against those challenges... Maybe there are some sexist comments being made, or there are some racist comments being made -- in some way, people are not being inclusive and not being accepting of the different members of their teams. I think it's OK to call them out on that, but of course, you need to very diplomatic about it.

Sometimes, it can require going to a more senior manager and just having a very confidential, very carefully worded conversation. Sometimes, if you think it’s appropriate and feel comfortable doing so, by all means approach the person with whom you have problem. And, I would wager that most of the time, that person hasn’t done this stuff intentionally, they’ve been totally oblivious to it. I've been around a lot of guys, white guys over the years that say really stupid things. But, then you kinda call them out on it and they go “oh, yeah...wow. I didn't really mean it like that, I shouldn’t say things like that.” Maybe they kind of take a step back and look at themselves, and realize that the behavior is not appropriate and not acceptable.

So, of course on the flipside, sometimes there are people that really do have horrendous beliefs and saying something to them, probably won’t have any effect. You need to be careful of those people. They’re usually pretty easy to identify. And, if there is somebody on your team, or you’re working closely with someone like that, sometimes the best thing to do is just distance yourself from them. But, for the most part, people generally have good intentions. And, helping them understand their own behavior, or their own challenges, I think is a really important step to take. It does take courage. I can understand it’s hard, but I certainly encourage you to use it.

So, I hope that answers your question?


I know, at least what worked for me in other industries...for certain situations where it could be more confrontational to talk to someone directly, sometimes it helps to have — “champions”, basically — that do work better and maybe the other person would actually listen to them more. Whether it’s that they have a longer relationship, or maybe they, you know — it’s (chuckles) “man-to-man” — they will listen to another man first, and then over time they start to learn.


I think that’s definitely true. People need role models, people need people that they trust and those people are usually the people they will accept advice from. And, in the diversity “problem space”, if you like, we need champions of all backgrounds and all walks of life. It has to be men and women and people of different ethnic backgrounds and religions. So, I think it’s important to try to find those champions — I think that’s a really great suggestion.


Oh, I do want to point out that yeah, there's clearly an issue with women and just in general, with ethnic diversity.

Myth of the “brilliant programmer.”

I think also, or at least from what I’ve seen mostly from the outside in although, maybe I see a little bit more here in New Orleans — ‘cause we do have a pretty open community — but, it seems there’s also this stereotype of the myth of the “brilliant programmer” — right? Ad it actually hurts everyone because it makes it seems everyone is at this really high level, or the people that are left. When really, it’s a bell curve. There are average programmers, there are great ones and then there are poor ones.

And so the myth of this “excellent programmer” kind of makes it OK to be a jerk, because all these really “smart” people are programmers. It would be interesting to see how to get beyond that, or to bring...it probably varies a lot by company but, it would be interesting to see what are some good ways to break that cultural myth in organizations that do have that [dynamic].


Yeah, well this is interesting ‘cause it’s kind of touching on some of the stuff I want to achieve in the documentary.

I think education is a big part of it. And I don’t just mean education within the technology space and preaching to the converted. But I also mean, helping teh larger public community understand what coding is all actually about. That it’s actually not this hyper-hyper intelligent, you have to be in the 0.001% of the population who even understand. There are certainly some elements of the software industry that are in that category, but they are such a tiny little piece of it. The vast majority of people, I think, can learn how to code.

And, I think that coding — I honestly believe in 50 years time it will be like reading and writing is now. I think most people will have at least some basic ability to program a computer. And, I think that making sure that — this is not an easy thing to do — but helping the community-at-large to understand that it's really not that big of a deal to learn how to code. It’s a creative passion, it's a creative pursuit. You definitely have to have a little bit of critical thinking, but you certainly don't have to be a genius, and by all means you don’t have to be some kind of almighty jerk, basically. Which is how a lot of Hollywood and media and so forth portray it.

I think that’s not an easy problem to solve, but that’s certainly part of it.


It also seems like one of the potential, major downsides of the “brilliant programmer” syndrome is that you end up fostering workplaces where people also feel trapped by that idea, in that they can’t show weakness, that they can’t ask for help, they can’t admit when they’re wrong.

I’m actually a little bit curious from your perspective Dan, having managed workplace and been in workplaces -- how do you make sure that there’s a culture in place where it’s OK to be wrong, it’s OK to ask questions?

Where it’s OK to be open about that fact we’re all growing and that we never stop learning?


Well, in a word I'd say empathy. It’s really, really important to have empathy for your fellow team members.

Now, I have an interesting story from many years ago, this was quite early in my startup days. I’d like to think that I handled it reasonably well, I probably would have handled it differently, had it happened now.

I had a developer on my team, he was a young man, he one of those inverted commas “a brilliant coder”, he was a very good coder — in the traditional idea of that term.But, actually he had terrible social skills. He had some anger management problems, he had no empathy for his other team members. In fact, it got so bad he lashed out on a few of my other employees, and eventually I pulled him aside and said “ look, I'm sorry, you’re an amazing engineer but you’re a terrible employee. You’re gonna have to go.” So, I fired him. And, it was a horrible experience, he broke down in tears, and we had this whole thing, and many years we actually met up for coffee and we talked through it. He'd kind of gone through this whole personal journey and improved.

What I came to realize out of this experience was that:

A great coder is not someone that can write an entire Ruby app on a weekend. A great coder is not someone that can improve your database query speed from 500 milliseconds to 10 milliseconds. Sure there's elements of those technical skills that you always look out for — but a great coder is someone that can work well on the team, can ask questions, can help their fellow team members. Can show empathy for the other members in their group, is willing to keep learning, and is willing to accept that not everybody necessarily understands things as well as they do, perhaps. Accepting that you may know something that somebody else doesn't — and vice-versa — that they may know something that you don’t, is a really important part of that process. Everybody on your team has something they know that you don’t. I think we can learn from everybody. Once again, it comes down to empathy, making sure that we don't get caught up in our own abilities, our own ego. I think for some people, that can be pretty challenging.

But then you’ve gotta think: if you’re ever in a position where you're hiring people, make sure you’re hiring for those soft skills first. Then worry about the technical skills later.


Yeah, I wish all hiring managers thought that way.



It’s taken me a few years to work it out.


I actually worked in public education and — this is something that we talk about a lot in urban public education — we’re trying to turn our schools around. A big thing they talk about is mindset, and it’s why some kids, they can never pass a test. But, it’s also why you get the “brilliant jerk,” right? The one that thinks they’re super-smart, but then won’t take risks, or they're always trying to make themselves look smart.

And, so how do you select for people who have more of a growth mindset, or who are more able to accept that they have more things to learn, or that they have faults? Because they're really in it more for the learning, than for trying to make themselves look good.


Yeah. Actually, that’s a really good point. I have another very short anecdote I’d like to share on that.

If I look back at my 22, 23 year-old self, I was probably sharp myself — I was probably a little too shap myself! And, my business partner and I had raised money for our company, and we had a chairman of the board that was established by the investment firm. I hated this guy. I hated him so much! We didn’t see eye-to-eye on anything, and we had some terrible fights and disputes.

Being challenged promotes growth!

What I realized, when looked back on that experience a few years later, I realized he was probably one of the most important people I’ve ever had in my life – despite the fact that I hated him. And the reason he was so important and the reason I didn’t like him very much, was because he challenged me.

He made me realize my mistakes and he made me look myself in the the mirror, and force myself to be more humble, and more embracing of what I didn't know. I think that was actually — as painful as it was, and an incredibly valuable experience for me — I think the times that you learn the most about yourself and most about how to interact with other people, is when you are willing to accept you are wrong.

And, we will be wrong, a lot! That’s the nature of technology. That’s the nature of life. But there are those that just simply, for whatever reason, are utterly unwilling to accept that and kind of learn from their mistakes. And, I just don’t think those people will ever grow and evolve as human beings, which is very sad.


So, we’re getting towards the end here, and I’d like to give everyone a chance to ask just a couple of more questions.

This has been a great vein of discussion.

STUDENT Q: [Andrew]

I had two questions.

My first question is: how common is pair programming in the industry?

And, my second question is: I know in the tech industry and how it’s growing in terms of the context of hiring, there’s a difference between startups and big companies and they ask for different levels of experience. Where some startups (are asking for) 5+ years of production experience versus, you know, some companies ask for two. How do you get your first step through the door, as someone from a coding camp?


Two great questions! I’ll start with the pairing one first.

Pairing is really common. It is common in different firms and agencies and companies. You’ll see some companies at one end of the spectrum where their entire work force pairs all of the time. That’s kind of an extreme case, but it does happen. There's an organization based out of San Francisco, they have office all around the the world now called Pivotal Labs. They are huge proponents of pair programming. I've met their CEO and actually got an opportunity to pair with him, and that's a core part of their whole philosophy, at Pivotal.

I think normally where you see pair programming is in the context of: “I’m kind of stuck on this problem, or, I’m not quite sure how to solve this problem or approach it. I’m going to find somebody else that I can buddy up with and nut it out.” And sometimes it might be someone that maybe knows that problem space really well, or someone that can mentor you. Or, maybe it’s a just a colleague that you value their input and would like to team up on something.

Pair-programming can be a lot of work, but it's very, very valuable. Actually, just as a quick side and this is a shameless plug, but if you take a look at codr.tv, we actually did a little episode on pair-programming. It’s under the “7 Habits of Highly Effective Coders.” Yeah, feel free to check it out.


We’ll link to that in the show notes!


OK, great!

Coming to your second question and talking about experience, and how do you break into the industry when ‚ it’s that age-old problem, right? They ask for two years’ experience — but how do you get the two years’ experience? And, until you’ve got the two years’ experience, it's...recursion.

The first thing I would say is, the people typically asking for that very often don’t really understand what it is they’re hiring for. It's often recruiters, they may not be coders, they may not be technical. The only metric they have to understand how good a coder somebody is: “how long have they been doing it?”

I know coders who have been coding for 10 years that are really not that great. And I know coders who’ve been coding for a year — and they’re incredible! They just pick it up, like a duck to water. So, I think that whole idea of, that the amount of time you’ve been coding is directly related to how good of a coder you are is actually flawed.

Sometimes, it can be related, but there’s no guarantee. So, the question then becomes, how do you deal with that, when recruiters or companies are asking for that kind of experience. My first response is: find a champion. Find someone in the organization that you can become friendly with, maybe see if they're willing to have a coffee with you, or a tea, if that’s more your thing. And, get to know them — ask them for advice, explain to them what it is you’re doing, what it is you’re trying to achieve. You can do this also by getting onto meetups. So Meetup.com like I mentioned before, has meetups in just about every city in the world. There’s JavaScript meetups, Ruby meetups, Python meetups, whatever. Get onto those, and try to network!

Because what I found, through one of my more recent startups — it’s called Codehire.com — what I’ve found doing research for that, is that the vast majority of good hires are made through referrals and through a network. Those folks that just come in cold and apply for a role through a website or on a recruiting site, tend not to be that good of a hire. And that‘s not because there’s necessarily anything wrong with the people who are applying but, because it’s very hard to gauge a good fit, if you’ve never met this person. You don’t know what their skills are, you don’t know what their background is, you don’t know what their passion is.

So, good hiring managers tend to hire from the network or from referrals, first and foremost. That would be my biggest piece of advice, on that front. Go and network, go and get to know people.

And I think the opportunities will start to come to you, once that starts to happen.

STUDENT Q: [Andrew]

Cool, thank you.


No problem.


Does that sound familiar...?

STUDENT Q: [Andrew]

Yes, it does.



I think we have time for one more question from the group here, or from outside?


As a side-note while we’re thinking, if you’d like to connect with me on Twitter after this, my Twitter handle is @danieldraper...perhaps, Erik you can share it?



STUDENT Q: [Deepa]

A quick question. So how do you stay relevant as a programmer?

And, what challenges do you foresee in the industry for the next 2 to 3 years for programmers / developers?


Good questions.

On staying relevant.

So, I think relevancy comes from living and breathing it (coding). I think it can be incredibly difficult to stay relevant in the software industry if you don’t continue to keep up with trends. Like I said, I've been coding for 20 years but there’s now, so much in the industry that I don’t understand or don’t know about.

I’ve recently, in the last 3 or 4 years I’ve started becoming much more aware of things like Angular.js, and React and different front-end frameworks. Whereas historically, I was much more of a back-end programmer. I think what you should do, it kind of comes back to what I was saying a little earlier, is be part of a network, try to get to a lot of community events. And, try to understand what people are interested in. What’s the latest language that people are talking about and what are they using in their offices or their companies?

Try and talk to them to understand what kinds of languages they think you might wanna pursue. Of course, one of the big challenges — this kind of comes back to what Sia was talking about before — say, if you’re a woman and you wanna go on maternity leave, or hey! You’re a dad, you wanna go on paternity leave which I think is an awesome idea, going away from the work force for a couple of years can be really hard to try to get back into it. So, if you find yourself in that situation, if there’s nothing else that you do, try to stay involved in those community events.

That’s probably more important than even coding itself, in some cases, is being aware of who’s who in the community and knowing what languages to pursue and what companies are hiring.

Sorry, you’ll have to refresh my memory on the second question, I got a little bit off topic there.

STUDENT Q: [Deepa]

What challenges do you foresee in the industry in the next 2 to 5 years for a programmer?


So, the industry as a whole has challenges in finding enough people, which is probably not a challenge for the coders themselves, you’ll find it pretty easy — so long as you have basic competency to find a role in the next 2 to 3 years.

We’re at an interesting kind of cross-roads in terms of technology, though. We've sort of have come from this world of PHP applications, Python applications, Ruby on Rails applications — you know, just static applications. In the last couple of years, there’s been this huge amount of interest in front-end frameworks, like Angular.js, React and so forth.

And actually, there’s a huge jump from building a back-end app to a single page application, like in building with Angular.js. I understand you’re all about to go into Angular.js training in the coming weeks — is that right Erik?




Yeah, so I think it’s extremely exciting — I love Angular.js, but it’s probably going to be pretty challenging for you! So, I wish you all the best in that. But, I think that’s a broad challenge, on a broader scale. So if you want to become an expert, in software programming, do then decide that: “OK, I'm going to know Ruby on Rails, and I’m gonna know it so well I can dream it.” Or: “Am I gonna learn Angular.js and do the same thing, or, how am I going to learn a little bit of both?”

And I think that's probably one of the biggest challenges for a coder — especially one that’s just starting out, this also applies to more experienced coders — is working out languages to specialize in and also, how much of a variety of languages and frameworks do they get to know?

So, personally, I’ve decided that Ruby on Rails is my speciality. I’ve been working really hard on my competency in front-end JavaScript frameworks and responsive design, and CSS frameworks and things like that. But then, there’s a whole bunch of stuff I've decided I’m not going to invest my time in. So for example — making iOS apps, or making Android apps. I kind of play with them, but in order for you to become quite competent in maybe 2 or 3 different areas, you need to specialize, to some extent.

The big challenge is which areas to specialize in. I don’t have a really good answer for you, but — like everything I’ve said — I encourage you to get to know other people in the industry and they may have some good advice for you.

STUDENT Q: [Deepa]

Thank you!


You’re welcome.


Well, thank you so much! Just wanted to go out on a piece of advice.

If you were sitting in these seats, if you were listening to this and just getting started on your career. Maybe you’re putting yourself in their shoes, or maybe putting yourself back in your own shoes.

In an area unrelated to the focus on actual code, what advice can you give “yourself” as a meta-levelized, budding and growing programmer?


What’s interesting to me — actually — I discovered so much more about the world and about my knowledge in general when I started listening to podcasts! That sounds like a really obscure piece of advice, but I think the message comes from this idea that learning is something that you need to be good at, if you're a programmer, because the industry continues to change — and you want to continually learn.

Widen your scope and capacity for learning.

Learning doesn't necessarily have to be about — you know, learning code. Learning can be, can be anything. I find that if you learn something about a whole new topic, something totally different, you’ll actually find that you’re doing two things: 1. You’re becoming a better learner. 2. You can start to assimilate different ideas, different ways and thinking into the way you code.

Personally, the way I have done that is I’ve gone onto iTunes and just downloaded all these podcasts. And there’s all kinds of interesting things, there’s like: RadioLab from New York and 99% Invisible in California, then there’s Freakonomics Radio and TED Talks, and all this kind of stuff.

I find that there’s just so many interesting things to learn and so many different perspectives on the world. I think that makes you a more well-rounded person, but it makes you a better person, that's able to code, as you go along. So, that’s the biggest piece of advice I have.


That’s awesome, thank you so much. Thank you, Dan, for sharing your time with us, from halfway across the world.


You’re very welcome!


Everyone else who’s been listening, whether you’re close or far, all of you, thank you so much for helping out. And, I think that’s a wrap for tonight. So, have a good one!


Nice talking to you all, thank you very much.

Contacting Dan


Personal Site


From n00b to ninja, we'll help you to become a developer
Subscribe to get expert guidance on learning, building, and getting hired delivered right to your inbox each week.

We guarantee your privacy 100%. Your information will not be shared.