Hey! This is the Daily Overpass! My name is Eric and I make apps! Now today, I want to
talk about why you should be the guide and not the code monkey.
For Overpass, I get a lot of calls from people
looking for apps to be developed. I mean, that's kind of what
we do. We do our own apps and we do client apps too. So, we get a lot of calls. I get
a lot of calls. Sometimes it's people with their own app ideas and some - a lot of times,
people looking for a revenue-sharing type of things which I say we don't do. And sometimes,
people with existing applications. So, we call the Greenfield projects which are new
projects and the Brownfield projects are existing projects. So, taking over some existing code
and working with it. And Brownfield projects are always much more difficult. It's difficult
taking over someone else's code because you don't know going in and anything about it.
Most of the time, I meant a lot of the time, when clients would come to us so be saying,
"I have this developer (laughs) who's driving me crazy..." I hear this so often. "I have
this developer who's driving me crazy and the project is nearly complete, we would like
somebody else to take over." And the kind of thing that I don't - I mean, you probably
know, you don't want to jump into something like that. That you want to say, "Uuughh,
we can have a look at it. Can we have a look at the source code?" And sometimes they may
give access to the source codes. They have even thought about that one when they went
into the arrangement with the previous app developer. So, one of the things I - I mean, I'm always
hearing about other app developers and complaints about them from the client's side. Of course,
I know if I went and talk to the developers I would probably hear their complaints about
the clients and vice-versa. But there's a lot of things that I hear over and over again.
And one of them is that the developer never gave me any advice. They would just ask me
what - they would just ask me what I wanted and if I said - if I wasn't quite clear, they
would say, you have to tell me specifically what you want. And whenever I ask them to
do something, they would just do it without giving any feedback. What I mean is, somebody
said to me yesterday, or a few days ago, they said, "One of the things I like about you,
Eric, is that you'll tell me if you don't like something that I say." And I do. Like
they'll come to me with something and say, "Hey, we really like the app that's out there
but we've been thinking about it - we would like to take the main form and put a button right
here (points at the right side) that says such and such..." And I would go, (thinking)
"Okay..." And then they'll say, "Oh that's.. Is it not possible to do?" And then I'll say,
"Oh, yeah, yeah. No, technically it's possible., I just don't like the way it looks. I just
think it will be confusing or you know, just sort of - it just don't sit well with me.
Or I think it will - for whatever reason." And it's my job as a software developer, as
a software developer who works with clients to express my opinion whenever they come to
me with something. But ultimately it's the client who wins out. It's their application.
They're the ones putting it on the app market. They're the ones who were footing the bill.
They're the ones who are doing the big thing that we all do with our own applications and
you know, trying to make them work, trying to make money. So you try to take what they
give you, what they ask you to do and do it for them. But also to be able to express your
opinion about it. Because there are two ways you can look at yourself as a software developer.
You could either say, "I'm the Code Monkey. Whatever they want me to do, I'll do because
I know how." Or you could say, "I'm their adviser. I'm the guide who's helping them through this
process." Because they don't know anything about apps, or they don't know anything about
- maybe the development side or releasing to the app store. But one of the things that
you as a software developer who's released apps onto the app market, who knows about
the coding side of things, you have to make sure that- first of all, that they understand
that that was your role. Your role as a guide, it's not your job to run the application for
them. It's not your job to take away all their problems. It's your job to help them through
the process and take any experiences that you have and lend them to them too. You're
not just a coder for hire because they can get that anywhere.So, one of the things I
would like you to think about if you do work with clients in the future is that you're
not just a rent-to-code. You're not somebody who's just - you know, I know how to code
so I can do this for you. You're a guide helping them through this because you've done it before,
you may have done it for your own applications or done it for other clients. And it's something
that's important for them to know. Not just for them to understand that you're not the
Code Monkey, but important for you to understand that you're not the Code Monkey because I
could tell you, with my first several projects, I'm pretty much just all myself as a coder. And
it really, really changes things when you start to change how you look at yourself.
Anyway, I hope that makes sense. Let me know what you, guys, think. And that's it for today.
I will talk to you, guys, tomorrow!