hey this is the daily overpass my name is Eric and I make apps now today I want
to talk about how sometimes it's my job to have headaches for my clients
okay so yesterday I talked a little bit about the problems in software projects so I
was talking about Apollo 13 and how it made me feel better because they had all
these problems but their best minds came together to fix them and how a lot of
times software projects are like this too
even though you might have really good developers on it really good designers
really good infrastructure things just go wrong and in software there's lots
of times there's so many moving parts that things just go wrong, you
have a network outage you might have some code that was badly written
there's lots of things that could go wrong right and one of my
jobs as when we work with clients is that I have to be able to take on those
kind of headaches. So a lot of times I try to make everything look easy to the
client even though it could be chaos and mayhem on my side. I saw this
way on every project but you know every project seems to have something that
goes wrong in it, so like a lot of times I'd be really stressed out with it, so
I'll be chatting with the developer on skype or on slack and I'll
be like, so where's that bill? I thought I was supposed to get that bill today? What
do you mean it's crashing? Why is it crashing? why do you think it's crashing?
And it will go on like this... Here, have you plugged into devices? Have you ever
checked logcat? I'll be asking all these questions and it depends, if it's a
really good developer they'll have checked everything but they're
at that point I happen to ask that at a point we all every bug that we ever have
there's a point where we don't we don't know what's caused it - if we did we
would have fixed it immediately, and sometimes it requires more investigation
and sometimes if you keep asking: "Why why why? This is urgent!", it doesn't
help the situation at all. So a lot of times I'm taking that on and sometimes you
just send me the code, I'll have a look at it too.
But when the client calls up for an update or when I'm updating the
client, a lot of times I don't tell them about all those little tiny things
because those kind of things, they creep up, you know. They happen we try to
to get rid of all that stuff before we go live, but to the client you have to be
calm and reassuring and, you know, everything is going good.
"Hey, everything's going great on the project, we just have a few minor
issues that we might need a little bit of extra time on, but nothing major. This kind of
stuff happens all the time, but everything's
going well. And it may sound a bit two-faced but one of the things I
realized years ago is that my job is to have the headaches for the client. My job
is not to make the client worry about things they don't need to be worrying
about - that's my job to worry about these kind of things, that's the developers job
to worry about these kind of things. And a lot of
times it's just trying to figure out what's happening here, you know, the
amount of times when we spent too much time trying to look at problems in the
code and we found out that it was the API that was giving us bad data. Or we might have
had a socket that was closed on a project. Yeah, There's always something.
There's always some little thing you find you, tear the code apart and put it
all back together when you find that one little loose screw that's just
messing everything up, and so on. And that's always the kind of thing, so like,
in the early days, I used to tell the clients - I used to feel like I
have to tell them everything that's happening. So I would tell them every
little problem that we had, and I realized that the clients were worrying
where they didn't have to. Because unlike them, I could fix it. I
had a bit of control over the situation because I'm a software developer. The
developer there might be a junior developer and they just don't know how to
solve it yet, maybe they're not familiar with checking logcat or
you know, there's something in there that we just we just
haven't found yet, and that's how you grow as n developer -its finding
these little things and going through them as much and as painful as it is.
So I can't lose control of the situation and just completely freak
out to the client because in the early days I used to tell them everything, and
I found that it wasn't happening. The reason I would tell them is because I
didn't want it to look too easy to them. I wanted a bit of recognition for
all the trouble I was going through, and it was all part of my ego thinking
" I don't want them to think that this is too
easy" because you know I'm going through a lot of stress here, and it was
something in my ego, I wanted them to know how hard I was working. But that
didn't really affect anything, and I found that in the end it was
but it was too stressful for the client. It was better that
I gave them the finished product. When we go through it, when we find
all those bugs and everything like that, these things come up, but what we
try to do is, when we give it to the client, we try to make sure we got
everything out of the way, everything is tested. But a lot of the times you get
chaos and mayhem on one side, and you got confidence on the other side. And one of
the things I realized was that a lot of times you don't have to tell the client
all the little tiny things that go wrong. I like to keep them up-to-date, I
like to let them know what's happening but you know sometimes things just happen.
Sometimes it'd be like, a developer has a problem where he doesn't understand a
bit of code, or we might have two developers working on
two different things and when we bring them together we have a little bit of,
like, they don't quite fit, these two components. Don't quite fit the way that they
should. So we have to to map all that stuff out, it just happens. So I
think, for those of you who do work with clients you probably know this already,
but, and I think about this when I deal with developers - a
lot of times developers will tell me things, and I want them to. I want them to
tell me every little problem that they have wrong, and also to not criticize
them for it, because we all we all have issues, we all have problems. I remember
working in corporate environments and somebody come to me: "Hey how come this
thing's not done yet?" I said "I just can't figure out. It's just coming up with a
blank screen and it's crashing at this one bit. I've looked at the stack trace
I've done this, I've done that", and really I've just started the
investigation, and all of a sudden they're freaking out because they think
I can't figure it out. But you know, at the time you happen to come
to me and ask me about this, I'm just figuring it out. If I came to you and tell
you about that then you know it would've been solved already. But this
kind of stuff happens. So my my message today is - a lot of times when you're
working with clients, it is part of your job to take on those headaches. It is not
the job of your clients to worry about this kind of stuff. And this
is something that I used to do just because of my ego - I
used to tell them all the stuff that went wrong in the beginning, but now
I don't now. Now I tell them technical difficulties. I'll
tell them what I think they need to know, when they need to know it. I know
that sounds two-faced, but that's the way it is. So anyway, that's it for today let
me know what you guys think, have you have a similar kind of situation? That's
it for today I'll talk to you tomorrow.
you