developers as entrepreneurs

A talk on how to prepare for a tech career after college with the DSC group of Strathmore University in Nairobi, Kenya.



Developers as entrepreneurs, or more broadly, how to think about your life ahead after you leave school. So towards that goal, we’ll ask ourselves what our goal is - what do we want to get out of all this? I had some thoughts on maybe where you could start preparing for work after school, some of the differences between school and work, some different ways to think about your career and your long-term plans, and then along the way, I think it’s really important to think about how you’re building your skills, and continually improving. After we go through all that, I thought we’d talk a little bit briefly just about my thoughts on entrepreneurship and maybe I can sort of explain how I got to where I’m at today, and maybe that’ll be of value to you. Then finally at the end, we’ll look at some low-hanging fruit, things that I think you can do today, or to more easily prepare yourself for your future.

I think the first big question really is what is your goal? Why are you doing all of this? I think if you understand the why, what your eventual hope to achieve is – and that’s oftentimes very easy to work backward to what you will actually need to do to accomplish that. So there’s a saying in politics that what people want is money, then fame, and then power, in that order. I actually think there’s a lot of truth to that sort of statement, but I think it’s kind of perhaps a little bit of a negative way of viewing the world. So perhaps if we were to rephrase these things, I would say that people want financial security, to not worry about where their next paycheck is going to come from. Influence and respect - people listen to you and value your input. Then finally, I think power just comes down to work/life balance. Being able to take a day off of work in order to solve a different problem in your life. So that, to me, is really a slightly more positive way of phrasing these things. The other thing is that the things that you want today are very often not necessarily the things you’ll want tomorrow.

I think this is important to remember because people will say they want one thing, then they finally achieve it, and then all of a sudden either they have nothing left to live for, they’ve lost the entire purpose, or they then decide something else entirely is their new life goal. I think it’s important to remember that you ultimately have to make your own decisions and make your own path. So you can’t necessarily just be wanting what the people around you want. For example, your parents may have dreams that are a specific list of things they want you to accomplish, but I think it’s important to remember that ultimately, it’s your life, you need to do that. The flip side of this is that oftentimes other people at a different point in their life can oftentimes see way more clearly where you should go or what you should do next. So this is part of why I think you should be talking to other people about your goals.

So, where to start? I think the simplest place for all of you to start is really, simply, the people that are around you right now. You’re in school, and perhaps in school, you have this mentality that you’re competing with each other to get a good grade. In order for one person to have the best grade, then somebody else has to not get the best grade, but I would suggest that these people around you are your best chance for getting a job down the road. You all may graduate shortly and a few of you may get jobs and a few of you may not, but it is my belief that in six months to a year the people who have gotten a job, their boss will come to them and say, “Do you know anybody else that could work here?” And this is an opportunity for each of you to hold the door open for your peers. So if I were to give you one piece of advice is that you should all work together as a group. So do your networking now, because I think you’ll find that the people you know in school oftentimes will go places in the world. If you can keep those doors open, down the road, it’ll pay off.

The other big thing I think you could do is try to get exposure to different tech and ideas. One of the joys of being in school is that you can try to do a lot of different things and dabble with many different things. Oftentimes, whenever you get out into the real world, you’re expected to pick a single area of technology and only work on that. So I think one of the cool things about school is basically you can do a bunch of little projects in a whole bunch of different areas and talk to a lot of different professors and by extension, you can find something that really resonates with you. Internships are another really good trick if you can do them. In the real world if you were to get three jobs in three months, you’d be viewed as being somebody dangerous to hire, so to speak. Whereas if you did three internships over a summer, you would be viewed as being some sort of a go-getter, somebody who’s really pushing the envelope of experience.

I think that’s just something really interesting. The other good thing about internships is that you’re working out in the real world, so you’re getting a little bit out of the school bubble and a little bit into the bubble of how businesses actually work, which is a really valuable source of perspective as well. Then finally I think if you look around you, you can find mentors - just people who are at different points in life than you, and by extension, many people for literally the price of a cup of coffee will talk your ear off about what they think you should be thinking about. Maybe all that advice isn’t perfect, maybe it’s not all entirely 100% relevant for you, but I think if you were to try and do that with a few different people, you could probably get some interesting perspective on where you are and where people think you should be.

So school versus work… I think the biggest difference between school and work is simply that you have a lot more time to work on a single problem. This can be really valuable. You can spend literally a week or a month trying to solve one little problem with a lot of uninterrupted time, but the flip side is that after working for a week on a problem with no headway, it can be kind of frustrating and difficult to keep on making progress.

One of the cool things about school is that you have smaller problems and there’s a much clearer idea of if you are succeeding or not. Whereas in the real world when you’re solving real-world problems, you’re often expected just to take something and bang on until it works, and then move on to the next thing. You’ve probably had the experience of working on a group project in school where you all work together - one person did most of the work, but a bunch of people who didn’t do any of the work got credit for it. Basically, I would say that in the real world, you may think that that’s not going to happen to you whenever you get out into the real world, but I can assure you that probably the reverse is the case.

Many times, I’ve seen people who didn’t do any work and they get the credit for a project. So I wouldn’t expect that to go away anytime soon. A large part of working together isn’t so much the working together, it’s just politics. Keeping people happy, keeping people in line, keeping everybody pointing in the same direction. This is just a really valuable skill for you to learn, because like I said, it’s never going to go away. I think one of the big differences for businesses is that in school, you solve this problem and if you solve a certain number of problems in a certain amount of time, you get an A - whereas oftentimes in the real world, you’ll solve the problem and then halfway through, the problem will change into a different problem. Likewise, if the problem is genuinely easy to solve, then it won’t be more than a few minutes worth of work. Then things will quickly switch up to a slightly harder one. So it’s constantly not quite really understanding what problem you’re trying to solve and not really quite understanding clearly what the solution is going to be - I think that is very much a common element of all this.

Then finally, you may think, “Oh, good, I’m done with school, I’m never going to have to deal with books and learning things ever again.” I would quite politely laugh at you, and tell you that your learning has only just begun. In the real world, probably half of the technologies that you’re learning today will be obsolete in five years. So it’s going to be a constant theme in your career that you’re going to have to periodically rebuild yourself from the ground up and relearn new subjects and techniques. So by extension, if you have a process for learning, understand your process for learning, and then ultimately keep that process going, I think you’ll be able to prepare yourself well for the real world.

So, how to find a job… Well, there’s the stereotypical big tech company job and many people will look down on that, or tell you that it’s not as sexy or as glamorous as other things, but I would probably tell you the reverse. If you can get a job at one of the big tech companies or something like that, then by gosh, you should go for it. One of the joys of working for a large company like that is that there are all these well-established patterns. You come in on the first day and they have an orientation for you. “Here’s what you’re going to do for the first two weeks, here’s what’s going to happen in the first two months, here’s what’s going to happen in the first year.”

If you’re good at following the pattern or fitting into the system, this can give you a very clear roadmap for working and how you want to do it. Likewise, in these sorts of companies, generally speaking, there will be very clear metrics. You need to do X, Y, and Z in a certain amount of time in order to qualify for a job promotion to move up that ladder. This oftentimes makes your life much simpler. Then ultimately, I think it gives you a lot of security. There are many companies in the world - where if you say you’ve worked at Google for two years, they assume that you can magically do a whole pile of other things.

So having one of these large companies on your resume is certainly a really good piece of long-term job security to enable you to do whatever you want in the future. Then startups are sort of the opposite world. Startups seem really sexy, I think, or people love to talk about them and whatnot, but having been on the front lines of a few startups now, I would say that startups are really just a lot of work and the risk versus reward is extremely high. For every person I’ve seen succeed at startups, I’ve literally seen dozens of others who didn’t. So you really need to understand that you’re getting into a lottery and not to believe that you’re going to be the one that magically breaks conventions.

One thing that is cool about startups is that you get to wear many hats since there are not really clearly defined processes and work, you can take on as many responsibilities as you like, for better or for worse. Sometimes people take on too much, and it ends up coming apart. On the flip side, if you work for a large company, oftentimes you will literally only work on say, one widget, or one screen of an app - whereas if you work at a startup, you can literally deliver an entire product yourself.

The other big piece of advice I would give you is not to pigeonhole yourself and not to think that you can only do one thing and that’s all you’re going to be doing for the rest of your career. The other flip side of this is that you shouldn’t take the path of least resistance. Just because you’re good at one particular thing doesn’t necessarily mean that that’s what you should plan on doing forever, and likewise, I wouldn’t tell you to necessarily try to optimize for money really early in your career because more often than not, that will lead you to less interesting jobs.

Then finally, the other conclusion to this is that your job and your career are two very different things. Your career is you over a period of time, but a job is just one little piece of that whole larger thing. So probably my advice to you would be to take more chances early. What this looks like for you, is a little bit more nebulous, but you shouldn’t necessarily try to be as low risk as possible early on.

16:32 Personal skills - these are things that all of you should do. Or rather, no matter what job or career you end up doing, these are all just valuable tools to have in your tool belt. The first big one is that being on time and prepared is always better than your technical skill. I remember a job I did once, I honestly didn’t know what I was doing, but I knew I didn’t know what I was doing. So I showed up the first day, literally five minutes early, and I knew we were going to be working with stuff, so I brought a pair of gloves.

I wasn’t the first person there, there were some other people there, but literally, a bunch of the other people that were working on this project showed up five minutes late or so, and they weren’t prepared. They didn’t come prepared to do any sort of real work, and basically, I remember on that project, the foreman would always take time out of his day if he saw that I was struggling. He would always come over and give me a few pointers and tips.

And likewise, there was a bunch of people on that project who really worked hard after that first day, but that foreman really never ever gave them a second chance in his eyes. Likewise, I personally worked on a project once where I came in the first day and basically made the boss angry, and literally after that, nothing I could do could really change things and so I ultimately had to move on from that place. This brings me to my second point, first appearances are really, really important. I wouldn’t tell you necessarily to wear like, a suit. Don’t overdress, so to speak.

But I’m always surprised at how many people don’t really take their appearance seriously, and so they look scruffy, and then they get treated like they’re scruffy, and they’re surprised by this. So I would tell you to observe the other people and try to fit into your environment. You don’t necessarily want to outshine everybody, but on the flip side, you certainly don’t want to be the worst dressed person there.

You need to save your money. I think this is easy to say and I hope it’s obvious to you, but I’m always surprised at people who start making money and then they decide to spend it just as quickly as it comes in. Ideally, you can save even half your money, or even more. This is easier said than done, but to me, if you can do something like that, if you can live simply, then by extension, we’ll say every month that you’re working, you’re buying yourself a month where you don’t have to work. Will you need that today? Maybe not, but at some point in the future having that sort of cushion or comfort is something that really gives you a lot of leverage, and lets you not have to worry as much about what other people are saying or doing, or being forced to make decisions that you don’t like. The other big thing I would tell you is to make time for your friends and family. Your family, oftentimes they do things at their own pace and schedule, and this is a royal pain, but these people are only going to go away. As you get older it gets harder and harder to make friends and your family will slowly evolve over time, and so you can’t really get back any of this time and energy.

So I would tell you just to try and make effort now to cultivate and keep these relationships going because a little bit of time and energy over a larger period of time is way more valuable than to try and disappear for a year or two and then come back and re-make friends with everybody.

And then the other side of this is taking care of yourself, just health and wellness. This is something I personally struggle with, I’m not really good at forcing myself to do all this stuff. I’m bad about wanting to spend time on the computer, but as you get older, putting time and energy into eating healthy and then keeping your body strong will only pay off as you go down the road.

So there’s this concept that is sort of the “10x engineer,” we’ll say - an engineer that’s 10 times better than the other people around them. People will tell you this is impossible, or that’s just a myth. I think that’s wrong. I’ve 100% seen people who can do stuff at an order of magnitude higher skill level than the other people around them. So, this is 100% a real phenomenon. But having said that, many people say, “Okay, in order to be the 10x engineer, then I need to maximize my skill, or be better than everybody else around me-” being a locus point, or whatever. I think oftentimes, the better way to be a 10x engineer is… Say you’re working on a team of 10 people - if you can double the output of each person on that team, then literally you have 10x’d your individual contribution to the thing.

I’ve worked on a lot of projects now over the years. In my experience, no developer I’ve met doesn’t have at least one or two holes in their technique, areas of which they can improve. Especially with newer junior programmers, it’s very easy to spend a few weeks or months working with them and make them two times or three times as productive. So doing something like this at this scale is 100% doable. Likewise, if you start working in larger organizations of 100 or 1000 people - if you can find a way to just improve everything by 1%… Compounded over that number of people that size of an organization, these kinds of things are very doable.

There’s a gentleman named Scott Adams who does the Dilbert comics, and he has this concept of a Venn diagram of overlapping skill sets. He says, “I’m not really that good of a comedian, and I’m not really that great at drawing, but by putting those two skills together all of a sudden, I’m really, really strong compared to everybody else.” So this is really important to understand your own strengths and weaknesses, and then trying to cultivate a particular little subset, or domain that you understand where you can really understand that little piece better than everybody else.

I will continue that saying, that domain knowledge almost always beats technical expertise in my experience. This is something I’ve seen many programmers struggle with. They think that they understand pointers, or c++ internals better than the next person. Then by extension, they’re a better engineer. Whereas the other person who understands why they’re solving the problems to more often than not can run rings around these people. That then leads to the big question which is something you need to be aware of: how does the company make money?

If you understand how the company makes money, then by extension, you can work backward to how you can make the maximum impact upon that thing. To continue my thread from before, many engineers think that if I just do a certain number of JIRA tickets more than the other people, then by extension, I’m a better engineer. But they don’t really have a global sight or understanding of what’s really going on in the organization. So they’re not really making as much of an impact as they might think.

It’s an important skill to always be learning. You need to be constantly cultivating new knowledge and techniques. For me, this just becomes a practice of reading daily. I try to be constantly reading. You don’t want to spend all day reading the internet, but I think it’s valuable to spend a little bit of time every day just following different threads and seeing what other people are talking about. I’m big on following trends. Many people want to be the first to do something, but I think oftentimes being the “second mouse” is a much better way of letting other people explore new stuff, and identifying technology is poised to go from being bleeding edge or niche into the mainstream, and then jumping on that bandwagon.

Another skill that’s important to do is to periodically pick up a new tool and learn it every so often. I periodically try to learn new frameworks or new programming languages – not so much that I’m planning on using them, but just to force myself to think about problems in a slightly new way. More often than not, I just end up going back to how I was doing things before. But every so often, I find a new area of a skill set and by extension, I have managed to tweak my own skills. I think the real crucial trick is just to know yourself. Understand what your weaknesses are and find ways to minimize your weakness.

Likewise, it’s important to know what you’re actually strong at and be confident in that, and find ways to hopefully make your strengths even stronger. These are just the timeless skills that you will encounter along the way – I think communication is literally one of the most important skills that you can work on no matter where you are in your career. I have a whole slide on this, we’ll come back to in a second.

Project and time management are just really important. If you can have a clear roadmap or picture of what all needs to be done, then actually getting it done becomes much easier. Likewise, if you’re good at time management, then oftentimes you’ll always end up with a little bit of extra time to solve problems. Whereas if you’re bad at time management, you’re going to be constantly fighting this uphill battle of not quite having enough time to solve problems. So sooner or later, a small problem will come along, and if you have that little bit of extra time, it’s no big deal. But vice versa, if you don’t have that little bit of extra time, those little things blow up and become big problems.

So if you can think about project and time management as a micro level, then the next level up is having focus and discipline at the macro level. To me, focus is just… To play off the time management piece, it’s knowing the “why.” The “What and why” is important, and then I think discipline actually follows very easily out of this. If you know that a bunch of boring stuff is going to lead to the goal you want, then it’s oftentimes very easy to do the boring stuff. Whereas vice versa, if you don’t have a clear picture of what’s going to happen next, then these sort of things just become meaningless grunt work.

On the flip side of this, I think many people become super focused on “to-do lists,” or things like that. I think it’s important to also make time for creativity and brainstorming – trying to think outside the box. It’s important to not always be 100% on and perfect in executing, but also to make time to get outside of that loop. This is something a lot of people struggle with. They can execute clearly, but they don’t really know what they want to do.

So like I said, I think communication is just the most powerful skill you can work on in general. This is just how I think about it. To me, there is internal speaking to the company – one on ones, just me talking with other people about what they’re doing and what they’re working on. They’re communicating within the team, keeping a group of people all working together, functioning, and keeping everybody happy. Then finally they are communicating to the company at large, speaking across all of the groups and divisions.

The flip side of this is external speaking – public speaking. Interacting with the general public and random people out there. Sales is a key piece to this, I think. Just finding people and trying to convince them to spend money with you, or to buy your product. Then marketing is a continuation of this where you’re writing down these messages and trying to encapsulate them into something so that people will see that and by extension understand what your company is and does.

I do a lot of writing. I think this is just a really valuable skill to cultivate in general. Whenever you’re writing your code, I think it’s really important to always be writing a little documentation. Many new programmers go overboard on this and they write thousands of words about this – I would tell you to maybe not go that far. I would say if you could open up a simple Google doc and write one to two pages about what your software does, the why, and maybe explain some of the problems you ran into along the way and some of the choices that you made.

Whenever you hand this to the next person who has to look at your code, then they can really get up to speed in a hurry. The other form of this is training people – onboarding them into your company. I think it’s important to be writing up documents for this, because if you give it to one person, they may find some stuff missing. You give it to a second person and they find some stuff missing. But after about ten people, all of a sudden a lot of this stuff can really become really smoothed and polished in a hurry. Not by doing anything particularly clever, but by documenting the problems you ran into along the way.

A lot of the work that I do is writing emails and memos to ping the right people to make sure that stuff is moving along. Likewise, whenever we do encounter a problem, just explaining what the problem is and outlining some potential solutions, and then trying to get people to weigh in and pick a particular direction for where we want to go next. These are outward communications, I would say.

I think another really important skill to learn is how to read people, understanding what they’re thinking, and what their motivations are. This is something I used to not really be good at. I still have a long way to go, but I think this is probably one of the most important areas in which I’ve made progress with over the last decade or so. If I understand when people are listening or not, or whenever I’m not hearing what people are saying, more often than not this allows me to really understand what the real problem is.

This brings us to the concept of entrepreneurship. I think I could probably spend an hour on this slide, but these are my high-level thoughts. I think the key concept is simply to build something that people want. If I could distill it all down, it would be that simple. The one thing most programmers do is they build something that they think is cool or something that they want, but they don’t necessarily go out and do the market research to see what other people would actually pay for. By extension of that, they can build gigantic, beautifully complicated demos that never go anywhere because it’s not something that anybody else other than them really understands or gets. So I would tell you to as soon as possible try to get other people to weigh in whether or not you’re going in the right direction.

In order to build a product, you need capital. Most people think of this in dollars, but actually, I think the dollars are the cheapest part of the puzzle, so to speak. I think the real thing that you have to be careful of doing is your time and energy. These are the things that more often than not you can’t get back. Time is measured literally as time, from beginning to end. Not how long you think you’re working on it, but literally the day you started and the day it got done. That’s just how I measure that. And then energy – I think you can get people to try something or you can call in favors to get a demo to work or get somebody to look at it, but long term… You have to have something that’s sustaining itself and powering itself if you’re wanting to actually succeed.

That brings us to the elusive concept of product/market fit – finding something that people actually want. I think if you can find this, everything else is doable. If you have product/market fit, then, in theory, your product is bringing in a certain amount of money, and then you can spend a certain percentage of that money on improving the product, and then either there is enough there to sustain the process, or if there isn’t, then you need to rethink things.

The key is simply trying to do as many experiments as possible for the cheapest cost. Like I said, many people think about this in terms of dollars. But I think oftentimes, one of my frustrations is whenever companies build something in house and they’ll end up spending six months doing something, or have a programmer work on a project for six months to a year when they could have just bought something off of the shelf for $1,000 and solved the problem that way initially.

Then finally you have this concept of market research. There is this stereotypical MBA that says, “Here’s the market, and here’s the percentage we think we can get, and therefore we can raise the money in order to get it and solve the problem.” But my experience is oftentimes the low-hanging fruit has already been picked. So oftentimes these business plans only make sense retrospectively.

Another element to this is to get off the beaten path. Sometimes today’s bleeding-edge technology that nobody is interested in can become tomorrow’s new hotness. So rather than trend-chasing, sometimes it’s valuable to strike out in your own direction and try to solve some problems that aren’t on anybody else’s radar before they get there, and more often than not then you start to uncover the fundamental problems before anybody gets to them, and you may be able to get ahead of the market.

And so like I said, I’ve worn many hats at this point in time. These are a few of the things I’ve done. At one point, I did a lot of our coding. I was coding alone, just building apps and putting them on the app store. We started working this company and we got some more people, so I became like a senior programmer. I would cut up an area for one person and another area for another person, and then my job was to try to make them meet in the middle or glue everything together.

From there, I started just managing the architecture of stuff we would work on. I would come in and build out a backbone for our app, and then other people could work on top of that. In order to do this, oftentimes I had to start coordinating with the back end and front end teams, so I started managing projects at a higher level where you’re just trying to get all these people in a room and get everybody working on the same common set of assumptions. But at some point, I evolved out of that and now I sit on the sidelines for the most part and just observe things as they go by.

Keeping an eye on the teams and making sure that they’re moving in the right direction is a lot of what I do now. We hire people, and just trying to make sure that we’re hiring the right people – continuing to add more technical talent to our team, but not necessarily get the wrong people, or try to hire too fast, or not hire the right people. That’s a problem.

A lot of what I would say I do now is prioritization – talking to people about what they’re working on and making them suggestions about what they should think on next, what they should be looking at, and perhaps more broadly than that, we might think about having a roadmap or some sort of quarterly goal or longer-term vision of where we want to be, and then saying… “If we want to be at this certain point, what all do we need to do to get there?”

Sales was kind of a large piece of what we did in the beginning. I did a lot of sales. I’m not going to claim to be very good at sales, to be honest. I know enough to get a warm lead over the finish line, but I can’t really do the hardcore cold inbound leads or that style of sales work. On the flip side, I would say that if I say something is going to happen on a sales front, generally speaking, I can make it happen. That is the one advantage that I have. I don’t really have to B.S. people, so to speak, on the sales front. I can actually make sure that the cats get herded.

Marketing to me is the flip side of sales. If sales is listening to the customer and saying what they want to hear, then marketing is writing down what they’re looking for and putting that out as your brand message. So people who are looking for something are finding you without you actually having to hunt them down. Then recently we’ve been working on building our own product internally, so I’ve been trying to weigh in on how to make this product better and improve it on a day by day basis.

But broadly, I thought I would leave you a joke, we’ll say. Where I am now, I don’t really interact too much with our individual programmers on our teams, I expect the project managers to deal with that for the day-to-day stuff. But if the project managers run into a problem, then they escalate things and they go to our engineering manager. More often than not, he’ll solve the problem there. If the engineering manager can’t get it, then we’ll give it to the VP of engineering. More often than not, he’ll solve the problem. If a problem makes it past all of these people, it ends up on my plate. Generally, I assume I’m not qualified to solve the problem, so I come up with some sort of an excuse to drag my CEO into the mix. So that’s where I’m at now.

Here are some next steps that I thought that you could do in order to think about all of this going forward. I think one of the big things that programmers can do is just create a resume or a portfolio site talking about yourself, showcasing yourself and your skills, and presenting yourself to the world. One of the cool things about this is that I think you can basically do it however you like. If you want to make things a certain color, then by gosh, do that. In particular, I wanted to call out is Susan. You had a little website for yourself that I thought was just really good. You had a blog on there with posts, and so I would think that would be a really good template of something you all could do as well. You might ask her for some advice on what she did there.

Like I said, public speaking and writing is just a valuable skill in general. It’s not really something that’s easy to do or easy to master, but I think the flip side is that if you understand that you’re not going to be good out the gate if you can just start finding excuses to do these things and force yourself to try and do it, I think over time you’ll find that it gets easier. Finding other people who could offer you advice and tell you what they think you should be doing is a really valuable trick.

Likewise, maybe you 100% understand what you’re doing in the world and where you need to be, but then I would tell you to flip it and look at the other people around you and see if there are ways you can help them move forward. I think trying different technologies and different business environments is just a valuable skill at this point in your career. I would advise you to dabble with various different things, if possible, just to try and get a different taste for all the different possibilities that are out there. Then hopefully you’ll find the thing that really, you think is your thing.

Then finally, it’s your life, so you need to make your path. It really comes down to you and your decisions. Nobody else can make them for you, which can be somewhat terrifying. But the flip side is that at the end of the day, you are the sum result of your decisions. So having that mentality, you can hopefully find the goals that you seek.

With that, thank you for your time.


Susan: Thank you. If anyone has any questions, perhaps you can answer their questions.

Brett: Yeah – Joseph is asking if having a background in business is a field that is valuable. I think there is a lot to be said about MBA-style skills. I think a lot of programmers pu-pu management and stuff like that, but I think this is oftentimes what a lot of real-world stuff ends up being – working for other people. If you can get an MBA, or if that’s something that’s interesting to you, I think that’s something that you could certainly pursue. On the flip side, I think you’ll find that a lot of business is not stuff that they can teach in school, or rather it’s dealing with conflicts and personalities and things like that. A lot of business knowledge is generic things or very broad advice. The specifics are the key to success in business, and nobody can really give you a clean template for that. Are there any other questions?

Susan: I would like to know, when doing internships or applying for work outside, they ask for experience. What is your advice about that?

Brett: That’s an interesting question. You need a certain amount of experience to get the job, and you need the job to get you the experience, that recursive problem. There are a few different ways. You can work on your own projects, and that can really open up doors. A lot of what we do is mobile development. Periodically a programmer will come through our door who has written an app on their own. It honestly doesn’t have to be an amazing app, or anything world-shattering. But to me, if somebody has gone through all of the hoops or the steps of building an app and actually getting it up and running on the app store, I’m certain that person is really going to be able to succeed in our company. That would be the simple thing that I would suggest that you do.

I don’t know what your coursework looks like at school, but I would think that having any of those sorts of projects would be really of value. So building a website is another thing that I think is not terribly technically complicated – anybody should be able to do it if you’re serious about working in this field. You can really present an interesting view of yourself, and by extension, get somebody willing to say, “I’ll take a chance on this person.” With respect to applying to companies, my experience is that there is the front door, the official application, and review process but more often than not there is the back door – reaching out to your friends who are working in the field and trying to make those lateral connections. More often than not, you’ll find that if you know somebody on the inside of those companies, they’ll be willing to let you not necessarily have to jump through all the hoops, and not exactly have to be 100% perfect in order to apply for the job.

Emmanuel seems interested in different types of companies and how to structure a corporation. If you’re genuinely just interested in starting a company, you can form an LLC for pretty cheap, at least here in America. I don’t know what the international equivalent is. But I would say that building your business up is going to be the more important skill than necessarily having a particular type of company – or rather, I would tell you that for a certain amount of money and paperwork, you can probably convert your company between any one of these different types. But the crucial trick then is getting to the point where you’re having enough business and revenue to where worrying about a specific corporation is important to you. But if you’re just getting started, I would focus much more on building a product that somebody wants to buy.

“Would you advise a developer to have an understanding of different languages, or to triple down on a specific language?” That’s an interesting question. I don’t know that I necessarily have a good answer to that. I feel like there are different areas, back end, and front end programming, and often times one language or another will work for a particular area. So rather than specific languages, I would advise you to have a backend programming language and a front-end programming language and have a couple of sets of styles. Then you’re able to have a foot in both of these different worlds. The big trend I’ve seen in general is that ideally, people try to do everything in one language for better or for worse, just because it makes everybody’s lives much simpler. So like right now, JavaScript and this whole node ecosystem and front end ecosystem seem to be on this gigantic collision course. So I think that’s just something that’s really interesting to be watching over the next few years. I think you’re probably going to have to interact with JavaScript in some form or another. Some sort of scripting language is valuable. Python in particular is a big piece of this. Then some sort of higher-level language like Java or maybe C is another big area in which you should probably be interested. But there are certainly a lot of new up-and-coming languages that I think are worth dabbling in.

Jimmy asked, “How can we build up our psyche to stay sharp and make critical decisions as you grow in your career?” I don’t know if I have a good answer to that. I feel like having a sharp mindset or being sharp is often a downstream of being successful. If you’re successful, I think you know you can make critical decisions. If you’re successful, even if you make a bad decision, you can bounce back from it. Whereas if it’s all or nothing on a particular decision, then all of a sudden the stakes get much higher and it gets much harder. I would suggest maybe not to focus so much on making the right decision, but perhaps focus on choosing and choosing quickly. Then likewise if you chose wrong, knowing when to admit that you’ve made the wrong decision, or knowing when to rethink things, and changing your mind – if you can do those two tricks, I think you’ll be able to handle whatever problems you encounter.

Abdul asks, “We started coding apps and publishing them – how is marketing /sales crucial at the start of the lifecycle of an app, company, or product?” In the beginning, we wrote a few different apps. But we actually never really made much money off of them, because we really did not understand selling them, or marketing them. If I was to go back in time, I would force myself to really think about what we were building and why, and are these people actually going to buy this thing? To me, the marketing and sales piece is really the key because as technical people, we can build things – but we have to be building the right things. So the sooner you can get out there and be talking to people and validating what the market is, the sooner you can say, “We think there’s something here.” Or vice versa, “We’re going on the wrong path and we need to switch directions.”

So yeah, I think sales is a super valuable skill because maybe people will be like… “Oh, yeah – we’ll build this thing, and everybody and their brother will buy it.” Then they spend six months or a year building something, and it turns out that’s not the case. If you could have that year back, that would be more valuable. It’s a really expensive way to learn. So talking to people is one of the cheapest ways to learn new stuff. As a programmer, I would much rather code than actually talk to people, but forcing yourself to do the uncomfortable thing of interacting with people out in the real world will get you much more feedback more quickly than sitting around banging on code all day. To be honest, if you wanted to go one step further, I’ve known a couple of people who literally had sales jobs – selling radios and electronics, and I think they’re really good at handling rejection, handling people… They’re just really good at that whole speaking part of the process. If I was to imagine a random thing to myself, I thought about literally just going out and getting one of those jobs selling knives at a fair or something. I just think that would be something interesting to do for a few weeks to work out any kinks in my skill with respect to talking to people.

Susan: [inaudible 1:02:29]… Some sort of team to start?

Brett: I think one of the joys of tech is that you should be able to… not necessarily build a whole project, but you should be able to build a prototype or something that you can show people so they can understand what you’re actually trying to build. A lot of people think they need to get a team and then the product will magically appear, but I would tell you to go in the opposite direction. Build something on your own, even just a simple HTML web app, just to nail down what your ideas are. Broadly speaking, I think you need to have some money in the bank and experience under your belt before you really start thinking about doing your own startup on your own. I don’t think that you’ll have a really clear vision of what the market wants, and you can really easily fool yourself into thinking you’re going in the right path, when in reality, literally working a boring job at a boring company for a year or two would teach you a whole bunch about the real world and how real companies work and how they talk together, then you can build a product that would appeal to them.

Miguel would like to know, “What are the rules of a UI/UX designer as opposed to a front-end developer in the creation of apps?” More often than not, the UI/UX person will be designing the interfaces, making mockups of what they want it to look like. Whereas the front-end developer will be the one actually implementing them. On a small project or a small team, sometimes people will do both of these things at once. But if start working with larger projects, larger teams, larger companies, these roles will be much more clearly delineated. If you worked at a really large company, there will literally be one person just in charge of UI design, and another person who is just a UX designer, and then there will probably be an entire team of people who implement those things. Where this gets interesting is oftentimes, this becomes very top-down. The UX person makes wireframes, the UI person draws stuff on top of those wireframes, and then the front-end developers implement those designs. So if you’re a front-end developer and you’re wanting to have a say in how the product is built, oftentimes on a large team like that, your input may be… Discarded is a strong word, but you’re going to be much further down the ladder than you think you are. If you enjoy designing interfaces, I think it’s a really valuable trick. But you need to be aware that this division of labor happens whenever you start working in larger teams and projects and stuff.

Jackson asks, “Have you ever been in a situation where you’re managing the client’s expectations? A situation where the client’s demands are impossible – how do you maneuver around it?” I’ve been in many situations where we’re managing the client’s expectations, and I would say that’s 100% a very large part of what I do. How I feel like I can help my team is just making sure that the client doesn’t have unreasonable expectations, and by extension, it’s impossible for the team to actually do them. It’s tricky to navigate that.

There are a few different strategies, but I think one of the big ones is communication. Just sitting in on meetings and listening to what people are planning on doing, and one of the ways in which I can provide value to my teams is literally being the person to say, “I don’t think these demands are realistic, can somebody explain to me how we’re actually going to do all of this?” and be the bad guy, so to speak. Impossible is a strong word, but oftentimes clients want it good, cheap, and fast – and of course, they want everything optimized in all these dimensions, and I think if you can reframe the problem and make them pick one or another, oftentimes it’s a really good strategy to get them to dial back their expectations or bring them closer to reality. The second level of this is a lot of times new clients, or people who aren’t really familiar with the whole development process are often the ones who have unrealistic expectations.

So just as in our career, dealing with more and more established companies and teams, I found that the impossibility of demands has actually gone down over time. So this is less of an issue now than it was in the beginning. But there’s this element of building up enough expertise to know when to push back, and it just takes time.

Manuel asks, “How’s it possible to integrate different programming languages and assemble a single project?” Yeah, many projects that we work on have many different programming languages working together. One of the key tricks is simply having APIs or whatnot that allow the different pieces of the puzzle to talk to each other. You might look at technologies like GRPC and protocol buffers. This is often sort of like a common thing. Then building sort of APIs that can interact together smoothly. Over the microservice level is a certain really important skill today, an important technology to look at right there sort of like graph QL, which adds a layer of indirection between all these microservices or services, so to speak, and lets everybody find a common way to talk together. But then the big trick is documentation and making sure everybody’s on the same page as to what is going on and why.

Andrew says, “How do you recruit a team in the startup when you are solo?” I think you have to work backward, Andrew - which is to say, I think you have to build a product to get some sort of funding or get somebody interested in putting more time and energy into the project. If you have that, then you can work back to getting people working on it. But like I said, you can’t get a team and then expect the team to magically produce a product. You have to build the product, and then you can build the team around that.

Jackson asks, “From a management perspective, how do you ensure the team is meeting their deadlines and targets?” One of the key tricks is just to make sure everybody knows what the deadlines and targets are. Here’s our goal that we’re working on, then here’s the progress we’re going to try to make this week towards our goal. Then the second level of this is monitoring this over time, sitting in on meetings, and saying, “Is the team on track to hit their goal?” If they’re going faster, that’s awesome. What are we going to work on next? Are they going slower? Where are they getting bogged down? What’s slowing the team down?

Then this is a gut feeling, but once you feel like the team is not going to hit their deadlines or their targets, then reaching out to your clients, and communicating with them. Oftentimes, one option is to get them to dial back their expectations. They may not realize that everything they want was as easy or as hard as they may have thought it was. So oftentimes the clients can say, “Well, you know, we don’t need all this, we only need 80% of this.” And by extension, you can cut your team’s workload in half. Then the other level is internal. Sometimes I can play games where I shift people around to get a little bit more help on something for a very short term. If we think it’s just needing a little bit more people on something short term, in order to make sure that everything reaches the eventual goal.

The sooner you can detect all this stuff, the better. The real trick is to tell when the small fires are going to become big fires before they become the big fires, so you can make small corrections now which over time will get your team to where they need to be.

Susan: Thank you so much, because we’re learning a lot, especially from your kind of perspective, a lot of things that we think about in this kind of history, we have assumed, and I am grateful that you’ve been able to clear that up. Before I finish, one last question.

Brett: Yeah, Manuel, you need to know Dart in order to work with Flutter. Then you’ll need to understand how to work with Android Studio. Then depending on what you want to do in Flutter, you may have to interact with the low level API’s, the stuff that Flutter is calling out to so you may need to look at the Android API’s proper. If you’re using the iOS form of Flutter, you may need to understand the iOS API’s proper. So with that, I’ll say thank you all for listening and thanks for having me. Have a good day.