November 20, 2019
Sometimes It’s My Job to Have Headaches for My Clients

Sometimes It’s My Job to Have Headaches for My Clients


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

1 thought on “Sometimes It’s My Job to Have Headaches for My Clients

  1. Nice video. Could you make a video on how much you should pay to advertisers to get downloads in certain country's

Leave a Reply

Your email address will not be published. Required fields are marked *