Iyfjky

Question

I'm thinking about this for a moment, and this place seems to be perfect to discuss about it.

I'm a freelance, and some time ago, I worked for a small company as a front-end developer (mostly JS stuff). This customer was already working with another freelance (back, mostly PHP stuff).

I worked 1 or 2 days, mostly fighting with the lack of methodology and collaborative tools (no git, no bug report, nothing). This freelancer knew I'll work with him one month before I worked with him. And the only thing he planned is a USB key so I could copy my code and give it to him.

During my time working on this project, we (my and the other freelancer) were mostly fighting with poor HTML/CSS and JS code that came from other people. We were really aware of that as we were constantly joking on this.

On the end of my mission, the customer asked me "What do you think about the code?". So I answered honestly: "We are working on a low quality base code, so lot of things can break up, it will be a pain in the ass to maintain, it's not readable and it could easily be more performant. In a nutshell: it will work, but it would be great to optimize some stuff". So, I was honest, too much maybe, because seeing his reaction, he wasn't aware of that. When I thought he was :)

The thing is: the other freelancer was there when I gave my opinion. And well, he became kinda mad at me, because I said this. He was aware of my point of view and agreed with it (his code wasn't concerned), so I guess he was mad because I told the customer what I think, because, - and this is what suprised me - he hasn't told the customer that was low-quality code.

I don't want to know who is right or wrong here.

The only questions I have are:

Was it "unprofessional" from me to tell the customer what I really think (considering he could never see it and there was no need to bother him)?

Considering that this freelancer was on the project before me, should I have "covered" him? (well, his work wasn't concerned, but let's consider another freelancer make dirty work)

Should a freelancer, in all cases, answer honestly to its customer/employer, when, in this particular case, it made an unconfortable situation and wasn't really needed?

EDIT FTR: My point of view in that was: the customer paid me to do some work and give some advices, so I have to tell him, regardless of what could other parts would think about it.

EDIT 2: When I explained the customer what I thought about the app, I didn't blame anyone, I just noted the relevant points, IMO.

Props for being honest with your employer, but FYI it's much more better for all parties if you address it before you finish the project(As soon as you find out). — Feb 22 '16 at 16:13
You did the right thing by being brutally honest. Only difference is you probably should have told the other freelancer that you were going to let management know that the code was sloppy so he could be prepared for what might come to him since he never mentioned it. — Feb 22 '16 at 16:33
@New-To-IT This is indeed something I could/should do, but I simply didn't think about it. This comment could be an answer :) — Feb 22 '16 at 17:12
@JustDoIt This is how it should goes, and this was what I thought. But I realized too late it wasn't :) — Feb 22 '16 at 17:15
The only thing I would have done differently is I wouldn't have said "low quality". You need to be honest, but clinical. This is the problem. This is why it is a problem. This is what could happen if XYZ and this is why I propose ABC. — Feb 23 '16 at 16:02

score 13 · Accepted Answer · 2016-02-23 14:24:23Z

I see the subject title of this thread has been made more definitive, so it warrants a more definitive answer.

"Yes"

If the choice is between being honest and potentially undermining someone or hiding the truth to support someone, you should tell the truth. Hiding deficiencies makes you part of the problem.

As a rule of thumb, I believe that if you're employed by someone, you should not underplay any issues or hide any problems from them. Whilst it's not always palatable, it's better to know the unvarnished truth, as this will prevent unexpected future delays.

Of course, getting Management involved can make life harder for those actually doing the work (sorry, Managers) but this will be as a consequence of a well-informed manager making a judgment call about their own priorities, as opposed to an ill-informed manager living in blissful ignorance.

Avoiding issues, downplaying valid problems or outright lying may well work in the short term but it is a rishy move. Should people find out that you've been withholding (or falsifying) information, your credibility will be affected. If you don't have the trust of your employer, it will be much harder to get work done (or indeed, to remain employed).

We could improve this answer with other answers. As @RualStorge pointed out, dodging the question or lying to the customer (to protect co-workers / predecessors) leads to a loss of credibility, trust, etc. — Feb 23 '16 at 12:57

RualStorge 9,5372231 · Answer 2 · 2016-02-22 22:44:10Z

While other answers do cover a great deal of concerns I do feel one very important argument comes into play here...

You were hired to perform several tasks by an employer, at the end of this the employer then asks. "Hey @enguenrrawns, what do you think of our code base?" well you really only have three choices on how to respond to this...

Tell them honestly it's a kludge and really needs some TLC

Lie and tell them it's A'Okay

Dodge the question wit something like "It's not my place to answer" or redirect the question to the other dev.

If the employer is asking it means one of two things... either A they are very proud of their code base and blissfully unaware of it's messiness, Or B there are already outstanding concerns and they're seeking an outside opinion.

In both cases honesty is likely to best serve you...

I'll respond from the perspective of the person who hires you...

Dodge the question

Okay, I asked you a question and you gave me the run around. That makes me not feel I can trust you to make decisions for yourself rather you'll just redirect the question to my subordinate, I asked you, I must have had a reason to ask you. This means you both prevented my from getting an honest answer as well as made me reconsider coming to you with this sort of question, and depending on the politics might strike you from my list of future work.

Lie / downplay it

So I've asked you what you think. I either think I've got the sort of code you see at NASA or I already thinking I might have quality issues.

In either case you tell me the code is fine eventually it'll come out my code is crap, and when it does your credibility goes out the window. This means I won't hire you again, nor will I recommend you to any of my peers. If we're using a service like Upwork this could also lead to a bad review which could cost you future business.

Honesty

Okay, So I've asked you your opinion either I think my code rocks or I suspect it's crap.

If I think it rocks and you sit down and go, "Hey buddy, sorry to be the bearer of bad news but this code is in rough shape." then walk me through the concerns and what they mean for me as a business... I may not like the message, but when I have someone take a look at it and give me their opinion and it matches your own you've just confirmed your competency over my current dev, and depending on what my current dev's been feeding me I might fire him and hire you, or when someone asks me for a dev they can count on I'm passing them your information.

Now let's say I already think there might be problems, but really don't know the scope of them. I also have concerns I can't trust my current dev to be honest with me here which is why I'm asking you. You lay down the law here and in the nicest way possible tell me my code is the stuff of nightmares. I'm shocked, I knew something wasn't quite right, but never imagined it was this bad. Well now I KNOW my current dev isn't doing me any favors (his problem not yours) and that your competent enough to see the demons and their likely consequences for me. Again I'll confirm your assessment, and once that's done you're on my A list for trust worthy devs. I might try to hire you, or at least pass your information on when someone asks me if I know someone they can count on.

Final note

While there is a possibility you could land yourself in politics you'd rather have no part of, when I hire / contract someone I'm not looking for a code monkey to knock out a feature and tell me I'm awesome (though that's nice) I want someone with a brain who's willing to warn me of things that might bite me later, or if you see someplace that could improve my revenue, reduce my overhead, etc tell me! Likely if you're the appropriate person to hire to do those things when it comes time to do them I'll go to you first.

I hire you to help me make more money either through increased revenue or reduced expenses, if you can accomplish that beyond the scope of my expectations you've made yourself a more valuable asset to me.

Some interesting points there. From what I understand of your answer, the best option in almost all situations is to be honest: can't loose credibility, makes you appear more "reliable" and trusty. — Feb 23 '16 at 8:30
Yep, and as a freelancer your credibility makes or breaks you. If people don't trust you, you don't get jobs. If people trust you then they'll be more willing to hire you over a cheaper unknown. (so experience and credibility tend to be the route to moving up in regards to quality of contracts) — Feb 23 '16 at 21:11

score 3 · Answer 3 · 2016-02-23 19:05:40Z

It sounds as though the other freelancer was adhering to a principle that can be encapsulated with the phrase, "Here's your piece of 'junk', ma'am/sir." Over the years, I've been in this situation more than once. I'm writing junk that should be thrown away. I know it, the client knows it, and we each know what the other knows. There are at least three explanations for it.

1) Sometimes it is cheaper to just "keep the wheels on" something that has a known, short, life expectancy--keep the TPS Reporting System alive until it's replacement arrives later this year.

2) Other times, a dysfunctional system is the elephant in the room that everyone sees yet no one is supposed to acknowledge or speak of openly, so don't.

3) Almost every system has some dysfunction. Occasionally, the level of dysfunctional is not widely known by management, and addressing the dysfunction is a first step towards resolving the dysfunction.

Because the messenger is often the one shot, speaking up and addressing the dysfunction can be brave or foolhardy, depending upon the outcome. Under #3, it's brave. Under #2, it's foolhardy.

On the specific question you ask in the subject line, I would say it depends, but mostly No.

It is possible to address dysfunction within an IT system without laying blame on anyone doing the work, past or present. Laying blame opens up the possibility that the person who was responsible is held in high regard by Management and other Stakeholders, whether it is deserved or not. Even if the person or persons you blame are no longer with the organization, or are not held in high regard, others may have been involved in decisions that led to implementing the dysfunction, so you are indirectly blaming them.

Why engage in a fight you don't need to? Just document the dysfunction without assigning blame. Neither the problem nor the solution needs to depend upon any specific human being. If you refrain from naming or blaming human beings in the discussion, then it increases the chance for logic and reason to prevail.

"Why engage in a fight you don't need to?" That's surely the point of this question: if he ask me, should I tell customer my opinion about the project even if this can lead to an unconfortable situation (that I have no benefit in) ? — Feb 23 '16 at 8:25
If the dysfunction was complete lack of some aspect that was some specific person's responsibility not inadvertently laying blame can be impossible (eg a "big ball of mud" style architecture is clearly a failure from the system architect if that position exists). — Feb 23 '16 at 20:48

Devario Johnson 191 · Answer 4 · 2016-02-22 16:31:03Z

This is somewhat of a double edged sword that I have been on both sides of.

When coming into a project there will always be someone that does something differently than you may have done it. The questions you ask yourself are, is this up to industry standard? Is this something that achieves the company goals and objectives for this project? Is this a viable solution for the issue presented?

If you can say yes to all of these then there really shouldn't be a reason to flame a former predecessor's work.

However if this is as bad as you say it is, you may want to check with the person currently there to see what solution was put into place as far as speaking to the business owners because you never know what type of political games are going on.

Sucks but it's a part of the workplace that we must be aware of.

You spoke to things like not having version control and other such things, however I will note that you never know the type of ridiculous situations and restrictions companies put on some freelancers. They may not have version control or anything like that because they 1) didn't have it before and feel things are fine and are scared to change or 2) simply don't want to invest time into it. You never know the type of ridiculous management teams that are out there.

It's up to you to educate them on these things and see if they would move forward with these new working processes. If not you are stuck developing the 90's or you can just move on. I see this stuff very frequently and it's a pain but it is what it is.

Education is a huge part of freelancing.

But to answer your question, if someone is already there in place, just clear it with him first. You never know the types of things that are in play until you have had a conversation about it.

I know the freelancer was working this way, I tried to convince him to use proper tools (I mean, it's not 1998 anymore). So I must say I was upset seeing nothing was done for collaboration. I'm also used to see lot of kind of code, so I know there is a lot of ways to write code (some better than others :) ). This time, it wasn't up to industry standard. At all. — Feb 22 '16 at 17:28

Kilisi 94.6k50216376 · Answer 5 · 2016-02-23 03:44:02Z

up vote
1
down vote

Too brutal.

I would have said that I would have done some things differently and there is plenty of room for optimisation, but I never outright disparage anothers work (if it works). Everyone does things differently and stabbing someone in the back is never a good look apart from being unprofessional.

For all you know the previous freelancer was the owners son, I have seen this scenario.

So be diplomatically honest.

Personally I just worry about my contribution, any high maintenance that's not because of me is fine, I charge by the hour for maintenance.

answered Feb 23 '16 at 3:44

Kilisi

94.6k50216376

"I never outright disparage anothers work (if it works)" but when you see things that doesn't work and makes your work more complicated ?
â€“Â enguerranws
Feb 23 '16 at 8:20

@enguerranws I get paid to solve complex problems, and I charge by the hour, I couldn't care less. I just let the boss know if I need to do extra for billing and reference purposes. I don't complain about the idiot who's putting money in my pocket.
â€“Â Kilisi
Feb 23 '16 at 12:38

Hmmm, that sounds brutal. I mean: I don't know about you and your job, but I'm not only paid to do things, but also to think about the things I do. And even if I also charge by the hour, I think it would be dishonest/disrespectful from me to charge my customer for something I didn't note / tell him before.
â€“Â enguerranws
Feb 23 '16 at 12:43

"I just let the boss know if I need to do extra for billing and reference purposes" That's what that means, I always clear extra work before doing it, otherwise they might dispute paying. I don't do anything unless it's been agreed first.... usually in writing if it's anything substantial.
â€“Â Kilisi
Feb 23 '16 at 12:44

1

Yes, but I mean, if you see something that will surely break in a near future, you won't tell your customer and wait for him to come back when he sees it crashing? I mean, the role of a professional is, mostly, to teach the customer (as the customer, by definition), don't know / can't know what he is paying you for). Not just to do and be paid.
â€“Â enguerranws
Feb 23 '16 at 12:53

Â |Â
show 3 more comments

score 13 · Accepted Answer · 2016-02-23 14:24:23Z

I see the subject title of this thread has been made more definitive, so it warrants a more definitive answer.

"Yes"

If the choice is between being honest and potentially undermining someone or hiding the truth to support someone, you should tell the truth. Hiding deficiencies makes you part of the problem.

As a rule of thumb, I believe that if you're employed by someone, you should not underplay any issues or hide any problems from them. Whilst it's not always palatable, it's better to know the unvarnished truth, as this will prevent unexpected future delays.

Of course, getting Management involved can make life harder for those actually doing the work (sorry, Managers) but this will be as a consequence of a well-informed manager making a judgment call about their own priorities, as opposed to an ill-informed manager living in blissful ignorance.

Avoiding issues, downplaying valid problems or outright lying may well work in the short term but it is a rishy move. Should people find out that you've been withholding (or falsifying) information, your credibility will be affected. If you don't have the trust of your employer, it will be much harder to get work done (or indeed, to remain employed).

We could improve this answer with other answers. As @RualStorge pointed out, dodging the question or lying to the customer (to protect co-workers / predecessors) leads to a loss of credibility, trust, etc. — Feb 23 '16 at 12:57

RualStorge 9,5372231 · Answer 7 · 2016-02-22 22:44:10Z

While other answers do cover a great deal of concerns I do feel one very important argument comes into play here...

You were hired to perform several tasks by an employer, at the end of this the employer then asks. "Hey @enguenrrawns, what do you think of our code base?" well you really only have three choices on how to respond to this...

Tell them honestly it's a kludge and really needs some TLC

Lie and tell them it's A'Okay

Dodge the question wit something like "It's not my place to answer" or redirect the question to the other dev.

If the employer is asking it means one of two things... either A they are very proud of their code base and blissfully unaware of it's messiness, Or B there are already outstanding concerns and they're seeking an outside opinion.

In both cases honesty is likely to best serve you...

I'll respond from the perspective of the person who hires you...

Dodge the question

Okay, I asked you a question and you gave me the run around. That makes me not feel I can trust you to make decisions for yourself rather you'll just redirect the question to my subordinate, I asked you, I must have had a reason to ask you. This means you both prevented my from getting an honest answer as well as made me reconsider coming to you with this sort of question, and depending on the politics might strike you from my list of future work.

Lie / downplay it

So I've asked you what you think. I either think I've got the sort of code you see at NASA or I already thinking I might have quality issues.

In either case you tell me the code is fine eventually it'll come out my code is crap, and when it does your credibility goes out the window. This means I won't hire you again, nor will I recommend you to any of my peers. If we're using a service like Upwork this could also lead to a bad review which could cost you future business.

Honesty

Okay, So I've asked you your opinion either I think my code rocks or I suspect it's crap.

If I think it rocks and you sit down and go, "Hey buddy, sorry to be the bearer of bad news but this code is in rough shape." then walk me through the concerns and what they mean for me as a business... I may not like the message, but when I have someone take a look at it and give me their opinion and it matches your own you've just confirmed your competency over my current dev, and depending on what my current dev's been feeding me I might fire him and hire you, or when someone asks me for a dev they can count on I'm passing them your information.

Now let's say I already think there might be problems, but really don't know the scope of them. I also have concerns I can't trust my current dev to be honest with me here which is why I'm asking you. You lay down the law here and in the nicest way possible tell me my code is the stuff of nightmares. I'm shocked, I knew something wasn't quite right, but never imagined it was this bad. Well now I KNOW my current dev isn't doing me any favors (his problem not yours) and that your competent enough to see the demons and their likely consequences for me. Again I'll confirm your assessment, and once that's done you're on my A list for trust worthy devs. I might try to hire you, or at least pass your information on when someone asks me if I know someone they can count on.

Final note

While there is a possibility you could land yourself in politics you'd rather have no part of, when I hire / contract someone I'm not looking for a code monkey to knock out a feature and tell me I'm awesome (though that's nice) I want someone with a brain who's willing to warn me of things that might bite me later, or if you see someplace that could improve my revenue, reduce my overhead, etc tell me! Likely if you're the appropriate person to hire to do those things when it comes time to do them I'll go to you first.

I hire you to help me make more money either through increased revenue or reduced expenses, if you can accomplish that beyond the scope of my expectations you've made yourself a more valuable asset to me.

Some interesting points there. From what I understand of your answer, the best option in almost all situations is to be honest: can't loose credibility, makes you appear more "reliable" and trusty. — Feb 23 '16 at 8:30
Yep, and as a freelancer your credibility makes or breaks you. If people don't trust you, you don't get jobs. If people trust you then they'll be more willing to hire you over a cheaper unknown. (so experience and credibility tend to be the route to moving up in regards to quality of contracts) — Feb 23 '16 at 21:11

score 3 · Answer 8 · 2016-02-23 19:05:40Z