Time differences

For starters, let’s say you’re in San Francisco and your work hours are 9~5. There is a 12.5 hour difference between you and your developer if you were to outsource. This is ignoring the fact that many freelance workers can work obscure hours, including myself. However, more often than not, you will find that nearly all of your communication with an outsourced developer will be via asynchronous communication, which can be extremely problematic when tackling projects of higher complexity. It also means that any urgent issues will take at least 24 hours to resolve (if you’re asleep and your SaaS comes back online, it’s not completely the same as you seeing it come online and getting a chance to make sure everything is in order).

Cultural differences

Before I continue, I’d like to point out that I have worked with freelancers in India and China both directly (hired by myself), and indirectly (hired by my clients). Not everyone is aware that there are significant cultural differences between North America and India. One of the most notable ones I like to use as an example is that developers in India tend to be “yes (wo)men”.

There are many times where project requirements can be vague, the developer may be having issues, but these things will not be clarified/communicated with the client. Throughout the project, you will often get the impression that everything is sailing smoothly, and it won’t be until the project is coming to a wrap, or when you get a demo of the project at regular intervals (you should be asking for this) that find you out a lot of things may not have turned out as you expected/imagined. Of course this varies from person to person and happens in North America too, and I’m not sure why this seems to be more prevalent in freelancers from India. Perhaps it’s because they consider asking questions and bringing up technical challenges a sign of incompetence.

Communication challenges

This is actually not as big of an issue if you can find a developer with a good grasp of the English language. Though most freelancers in India are knowledgeable of English to some degree, more often than not, the challenges with communication begin to surface as you get into more detailed parts of the project. This, combined with the 2 points above, make it very difficult to move a project along and adapt to changes smoothly/efficiently.

Maintenance and code quality

Okay, this one is highly subjective and really happens within North America too. Often times, you will find that the code delivered by an outsourced developer works. Maybe you find a few bugs, and they get fixed. Great, right? The challenge is not actually getting everything to work. A huge issue that clients don’t consider when choosing to outsource is code maintainability. You might say, “I don’t understand code, and I don’t write code, so why should I care?”. Really, you should care a lot. Many times, instead of working with the client through technical challenges and pointing out that the deadline may be too rushed, outsourced developers will come up with “hacks”, and many of these combined end up making the product extremely brittle and prone to breakage. Breakage aside, any developer who has to work on this product further down the line will have to battle themselves whether to retroactively clean up those “hacks” and risk breaking things that appear to be working, or just building on top of the technical debt that has already been accrued. As the technical debt builds up, you will find changes taking more time, and (seemingly randomly) breaking other unrelated parts of the product. A quick hack can cause many headaches and become very expensive in the (near) future.

Cost

By and far the number one reason to justify outsourcing overseas is the cost savings. Many small business owners who are not technical and have not had prior experience outsourcing projects overseas are not aware of the risks and headaches that come with outsourcing. It’s not uncommon to have someone contact you about estimating a project and having them scoff at your rate then talk about how they can hire someone in India for $5 an hour (to be fair, these kind of clients are on my never-ever list too). And to get a good developer in India, even $5 is too low.

However, as mentioned in one of my previous posts, the math doesn’t usually work out the same way you’d expect it to. On one hand, the developer from India might quote you 700 hours at $5, which ends up at $3500. Someone local may charge you $150 an hour, but only bills 30 hours, which ends up only being $1000 more than the alternative. This is a bit of an extreme example, but it also disregards the savings from avoiding the issues related to outsourcing overseas. This discrepancy in hours billed may be caused by a different skill level, or they may simply be billing dishonestly (which can occur anywhere). Hourly rate is not a good indicator of value provided. This is the reason why some of my clients are charged based on blocks of time (think day/week basis). In fact, the working relationship between client and freelancer is also incredibly important. Someone who has worked with your company for an extended period of time likely has a better understanding of your business and is able to provide solutions that are tailored specifically towards your business needs. From personal experience, there have been times where I would propose a different solution, one that would make me less money, but would ultimately be a better choice for the client.

Okay, but when should I outsource overseas?

As someone working mostly in North America, my opinion is definitely biased. But while I have seen first hand the many issues that come up with hiring someone overseas, I do believe there are instances where it can make sense for your business. Projects that are smaller in scale and more isolated from the critical parts of your business, which have clear requirements specifications, may be a good choice for overseas labor from a cost perspective. The issues listed above may still apply, but having a smaller project, along with clear requirements specifications will go a long way towards helping mitigate/lessen the impact of the those issues. Depending on your budget, it may be your only option.

The post Outsourcing overseas first appeared on Jay Huang.

They have problems or goals for their business and they want me to use my skills and experience to tackle those problems. Since they are paying for my time and trust that I will help make them successful, my opinions and suggestions are taken seriously. They may not always agree with these suggestions, but that’s good because it moves us forward and allows us to further test and analyze these ideas, quantitatively.

However, being used to this kind of process makes things very different in other areas of my life. I regularly visit developer communities online to see what’s going on and seek out interesting questions people have. And after all this time, I’ve found most of the people who go online looking for “suggestions/advice” really aren’t looking for suggestions.

They are looking for their views to be accepted and validated; most of them are not willing to accept differing views and will continue to ask and amass a ton of opinions until they find one that matches their own. Of course there are people who are genuinely looking for someone else’s perspective and take it into heart. Only, on the internet, there is no insight into whether or not someone has really gone back and followed through with your advice.

It’s a world vastly different from what I’m used to as a consultant, and one that frustrates me greatly. It doesn’t frustrate me because random strangers on the internet aren’t listening to me, it frustrates me because as an introvert, I listen far far more than I speak. And it becomes very clear that many people do not know how to truly “listen”.

A couple years ago, when I was in the middle of my last co-op term, my co-op instructor from BCIT visited me at SAP. He brought up that my co-op report was one of the most well written he’d seen (probably because no one who writes these reports actually cares about them), asked me if I ever considered becoming an instructor, and that he thought I would do well as an instructor. I didn’t really give him an answer because he was an instructor himself, but the answer is pretty much no; I did not ever consider becoming an instructor and I don’t think I have a desire to become one. Regardless, we were chatting happily, and he asked if I was returning to school after my co-op term. I said no because I decided to put school on hold as I had a couple full-time offers.

He then asked me if I had any suggestions for the department’s co-op program. I said not really, but he insisted, so I thought, “why not?” and told him my biggest issue with the co-op program at BCIT (as nicely as I could). I suggested that maybe, just maybe, it would be nice if we had more job postings in general, and with more reputable companies (as opposed to mostly small local shops). The fact was places like UBC and SFU had job postings in the hundreds, ranging from large corporations to small shops, while BCIT had less than 30, with half of the postings littered by EA (Electronic Arts), which was known for not hiring from BCIT. He instantly flared up and went off about how he’s been putting in so much effort to get postings for students and how I’m ungrateful for the awesome opportunities provided to me.

This came somewhat as a shock to me. I’d expected him to be upset because it was in a way, questioning his competence; but not to this extent, and it was certainly not my intent. After all, he insisted that I give him suggestions. It became apparent to me that he probably wasn’t really asking for suggestions, he simply wanted acknowledgment that he was doing a great job. Bit of a round-about way of asking for validation if I might say so myself.

This experience, along with a couple others, is the reason why when I ask for feedback, I ask for 1 thing the person likes about my work, and 2~3 things they don’t. It’s also the reason I will hesitate when being asked for feedback. Most people are conditioned and prepared to give positive feedback. It’s quite simple logic that if you have nothing to gain, there’s no point in saying something that may cause someone to be upset with you. Encouraging and acknowledging the possibility that you do not, in fact, know best gives people more room to present to you their raw, unfiltered perception of your product/work. Limiting the feedback to a small list allows you to identify the most important points and areas you need to work on.

I know a few companies where this is baked directly into their recruiting process. They will ask a candidate to try their product, and come up with areas where the product could improve. While I think this is a great idea, it doesn’t happen nearly enough. If all you want to hear is boilerplate “courtesy feedback”, don’t waste anyone’s time at all. Clients pay consultants to find inefficiencies, areas to improve on, and markets to expand to. So if you’re lucky enough to have someone willing to give you feedback, take the time and put them at ease. Make them feel comfortable enough to point out flaws. Embrace contention. And if they really only have positive feedback, don’t settle for “it’s awesome!”/”it’s great!”/”I love it!”. Be ready to ask why. Ask what makes this this piece of work awesome/great. Ask to be challenged.

The post Giving feedback first appeared on Jay Huang.

One would mean I would be moving to Palo Alto, California, where I would be joining a well-known, highly successful, technology company. The pay was great, and working there would make any future job hunts virtually non-existent. The only possible downside to it was having to move. A few weeks prior, I had just completed the final steps of becoming a homeowner, and moving to Palo Alto would mean having to put my place back on the market within a few short weeks. Nevertheless, I was not too concerned. Having lived for extended periods of time in Taiwan, Australia, and Canada, I’m very open to moving and even embrace the thought of living in a different country, with major differences in culture.

The other offer would mean staying in familiar old Vancouver, in a company that had one claim to fame (a relatively impressive one at that), and noticeably lower pay. If that were it, I would have moved to Palo Alto in a heartbeat. But that wasn’t all. The product that I was offered to work on was something that I was extremely excited, and passionate about. In fact, it was something that I had been giving a lot of thought prior to hearing about, and not only was I excited to hear about its existence, I was even more excited to be one of the two developers working on it.

After weighing my options and deciding that I didn’t really want to pass up the chance to build something I was so passionate about, I happily took the lower pay (and prestige) to join the team. I was not too concerned about money because it was something I had been dreaming to build. I certainly did not think about much else at that time, I just couldn’t wait.

The team consisted of 5 people. The PM, copywriter, UI/UX designer, myself, and the other developer. Everyone else in the company was working on other products. In terms of the executives, they were very much detached from the operations of the team.

And so began my short 9 weeks at the company. Within days, a big red flag was placed in front of me, but I was still so oblivious and excited that I shrugged it off and pushed it aside. Two unfamiliar names were mentioned in passing a few times. Curiosity kicked in, and naturally, I asked who those two people were. It was always glossed over with something like “they used to be here”, and very little more. After a couple meetings, I was able to slowly piece together some information about those two people. One had worked for around 3 months, the other worked for around 5 months. No one was able or willing to drop hints as to whether they left or were fired. But either way, after the first one left, the second one came, then when that one was about to leave, the other developer I worked with came along.

It seemed weird to me at the time, that for whatever reason, people were coming in and whether quitting or being fired, leaving a product that was solving a big problem, with quite the market — so soon. But I didn’t worry too much about it, as all I could do was speculate and probably come to the wrong conclusion.

Soon after, there was an “optional” beer party. It was a Friday (I believe) night, and this beer party was from 5~9. My mother being in poor health, I stayed for maybe 45 minutes, spoke with a few people so as to not leave so abruptly, had some water (I don’t drink), and left. It was a pretty tame party anyways; there were maybe 8 people sitting at the kitchen table (including our PM), talking loudly about random gossip, 2 or 3 people re-filling their beer cup, 4~5 people around the ping ping table, and the rest were just sitting at their desks browsing whatever they were browsing, and looking bored. After all I thought, it was an optional beer party, it wasn’t celebrating anything within the company in particular, and I already saw some other people leave. Surely it was perfectly fine for me to leave around 6 to look after my sick mother? Apparently not. A few weeks later I would find out that this party wasn’t quite “optional”, but more on that later.

So the next week, it was more code, code, code, preparing a working demo for our investor, code, code, code, racking my brain and its terribly short term memory on what I worked on the previous day for our daily morning scrum meeting. Near the end of the week, we had another push from the development to staging environment. After doing some testing and resolving some bugs, I came across a XSS vulnerability in the product. Now, depending on the vulnerability, XSS may or may not be a huge issue. However, our product was dealing with large amounts of money from customers’ bank accounts, and this vulnerability made it possible to break large portions of the application. Most importantly, it allowed the transactions of users to be skewed, allowing malicious users to cause other users to essentially lose money, or worse yet, put them in a potential dispute, and ultimately, cause our product to lose customers.

“Stop fucking around and get shit done.”

I brought up the discovery of this vulnerability, how critical it was that we resolve it, and the horrifying impact of it. But no one seemed to really care. The other developer said we don’t really have time to fix it, but it was clear he also recognized the potential dangers (and at the same time, the PM was pushing us hard to make more “pretty stuff”). The PM said “stop fucking around and get shit done”. Those were his exact words. Another red flag just whacked me in the face. At this point, I was frustrated, but what was I supposed to do? If I went ahead and allocated time to fix it, I would have to deal with an already ticked off PM who seemed to think fixing critical vulnerabilities is “fucking around” and non-productive. I decided to put it on the back burner and bring it up again when an opportunity presented itself.

Code, code, code, demo, meeting, code, code, code, meeting, code, code, code. On it went. Deep down, I felt that something wasn’t quite right, but I continued to ignore the red flags that seemed to constantly appear. But hey, at least the work life balance seemed okay. I mean everyone was leaving after 8 hours a day, and sometimes I would work a bit longer than everyone else, but that’s okay, because it’s on my own will and it’s usually a feature or bug that I just have to get done.

“You are not 100% committed.”

A few days later, the PM says he wants to speak with me. What I thought was going to be a nice conversation turned out to be anything but. One subjective issue, and 3 questionable points. “You are not 100% committed”, he said. Weird, I don’t understand how that can be. Surely I am the best judge of whether or not I’m committed? And it’s quite apparent to me that I am 100% committed and truly care about the product. He would repeat this 2 times before finally enlightening me on why he felt I was not 100% committed:

1. Apparently, I wasn’t committed because I had not updated my LinkedIn profile since starting this job a mere 8 weeks ago.
2. My website is still up, and my website is (still) selling my freelance services to clients.
3. I also haven’t been working overtime on a regular basis (aka every single day of the week). “I’m not saying you should be working 80 hours a week, but 70 is not ridiculous to ask, and if you were committed you would do more”.

I didn’t understand this at all. I asked him if he felt my performance was lacking. No. So somehow, these 3 points are telling him that I am not committed. Here’s my problem with these “points”:

1. I hadn’t yet bothered to update my LinkedIn, because it takes up more of my time, something I’m not yet ready to do, and I’ve been told that updating your LinkedIn tells an employer you are on the hunt for a job again. I definitely did not want to give that impression. Furthermore, being a co-worker, he stalked my profile multiple times yet never added me? That seems more of an issue to me than anything. The other developer, who I worked quite well with, added me the day I accepted the offer. I’m not saying adding someone on LinkedIn should be a requirement, but if you’re going go off worrying about my profile, wouldn’t it make sense to send me an invite to connect? To each their own I guess.
2. Why would I take my website down? It’s part of my brand and it gives people easier access should they need to contact me. As usual, it hasn’t been re-designed for a while, because I simply do not have the time. The simple truth is I do work with clients as a freelance developer, so why would that not be on my website? The funniest part about all this, is when I was discussing the offer with the HR lady (the PM was also present), I brought up the topic of side projects outside of work, and my freelance work. As I do have some clients on retainer, it would be impossible for me to suddenly end my agreement with them. They both said “Oh no no, we definitely do not want you to stop your freelance work, in fact, most of us in this company have side projects outside of work, and that’s something we love and embrace”. I’m not kidding. That was part of the reason I didn’t move to P.A too. Yet in a short 8 weeks, that’s suddenly a problem.
3. I’m not new to this industry. I’m well aware that overtime happens, and in fact, it’s quite common. I’ve worked till 10:30 PM once or twice when I was at SAP. And sometimes some critical bug or release has to be finished at all costs. I get that. There is a reason for the overtime, usually a good one. But what my PM was talking about, wasn’t about any release in particular. It was simply “you’re not committed because you’re not working 70+ hours a week”. It’s been proven time and time again that constant overtime produces less value, and in fact, may even cause you to break more than you build. It’s simply impossible for someone to code for 70 hours a week and not break things and eventually shutdown due to burnout.

I tried to address these points with him in an amiable manner, but it was impossible. All he would say was “well…” then go back to talking about how I am not giving him the impression that I am committed. He also brought up the fact that I left the beer party early and that further reinforced his idea that I wasn’t committed.

A few days prior to this incident, I had already been thinking about that job. And the red flags I previously mentioned, plus a couple other things, made me wonder if it was even a good fit for me at all. It’s against my nature to not work at resolving issues, but in this case it seemed he wasn’t receptive at all to my opinions, or simple logic, for that matter. After this “discussion”, I went home and thought a long time about it. I would speak with him the next day, and try once again, to resolve the issue. If he was still not receptive, I would give notice to leave.

The following day, I worked hard to make sure that if I were to leave, I have left my work on the product in a good place, then I went to speak with the PM again. He was completely unwilling to discuss anything, and repeated the same accusation of me not being committed and the 3 feeble points to back up his statement. At that moment, I submitted my resignation. He was indifferent. He said “well if you don’t hand off your work, some people are going to be fucking pissed”. I told him that I had every intent to make sure all of my work was accounted for and that there would be no difficulties to progress without me. I had already documented large portions of my work, and it was all very transparent. He said come in tomorrow to do a knowledge transfer.

That night, I was going through my email, Trello board, and JIRA issues to see if there was anything I still needed to hand off to the other developer. While I was looking through my email, I was suddenly disconnected from all services (Google Apps, Trello, JIRA, Bitbucket). This left me a bit confused as to whether my fob still was able to get in the door, I did not want to travel 1.5 hours just to realize I was locked out. But I went the next day anyways, assuming he was just trying to protect company resources.

The next day during scrum, he announced to the team that I would “no longer be working here”. I did not care much about it, but it brought me back to thinking about the 2 previous developers on the team. I guess that would be how things would be explained to the future developer too. When I sat down at my desk, he told the other developer to make sure I didn’t make any code changes. At that point, it really felt like he was giving the impression that he had fired me. But I chose to remain as professional as possible, doing my knowledge transfer, not causing any drama explaining to people why I am no longer working there. Around noon, everything was done, and he told me to leave, and give my (personal) password to the other developer. I told the other developer that I would like to wipe the desktop myself (with his supervision of course), and change the password, then give him the new one.

It was time to leave, and the HR lady came to me and said I would have to sign a release letter and send it back within 2 work days (the following Monday was a holiday), otherwise I would not get any of the remaining pay, including my “stock options”. Apparently instead of full-time as stated in my offer letter, I was a “Contractor” and the agreement between us was “terminated”. I guess that’s to protect them somehow. And the “stock options” that she said I would be paid amounted to $0 (as expected).

To this day, it remains difficult to explain to people why I left that job after a short 9 weeks, and I make sure not to paint anyone in a bad light, and not name the employer or anyone else. Yet somehow, I feel that everyone else besides the PM thought that I was fired instead of leaving. I’m pretty sure that’s what he’s been telling people anyways. Oh well.

Join the discussion on HN: https://news.ycombinator.com/item?id=6693066

The post A culture of beer and overtime first appeared on Jay Huang.