Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Founders, what is the worst experience you had with developers?
93 points by oldboyFX 6 months ago | hide | past | web | favorite | 97 comments
And how did you manage to solve the problem?

I have interacted with off-shore development teams from a specific country 3 times now. I'll say the country later.

Every time the development team could not grasp what was required. You literally had to exchange 20 emails with them for each specific point. Of course, this just increased the length of time for scope and in all cases furthered the time of the project.

Each stage of the application was over engineered to infinity. Spaghetti code everywhere and nonsensical functions, callbacks, literally everything was what the hell was the developer thinking.

Of course it just about worked. They had to ship something, but it was slow. The UI was painted into a corner, in some cases doing the wrong thing literally crashed the browser because of an infinity loop or took too much memory.

Some apps had about a billion dependencies and therefore could never be secure. I'm not kidding either, it's like the developer was a plumber instead of actually knowing how to code the simplest of things.

There was no way to ever extend it to build atop newer features or have any sort of roadmap for user requests.

In every single time, management outsourced and took the bid from the lowest priced company. How to solve the problem? Start from scratch with a competent local company with an actual design and development process.

Want to know the best bit? One company I know of, who spent $6 million dollars on a project with an Indian company. An in-house developer took 3 months as a side project and rebuilt it from scratch. It ended up being the code from there on in.

I have NIH syndrome due to seeing these issues pop-up time and time again. In my career I've seen well over $15-20m being wasted in projects due to management being completely incompetent and thinking sitting on the phone with a dev team will ensure success.

Not sure what your point is here.

Your company chose the lowest priced company and was surprised when the quality of the work wasn't great. Because this isn't just unique to just India. This happens everywhere. To counteract this story. I worked at Apple where they used offshore engineers from India and the quality of the work was excellent.

You get what you pay for.

They chose the lowest priced company because they didn't know how to spec the tender properly and to do a proper risk analysis.

The lowest costs, of course, will win out in this case.

How would one do it properly then?

One can't. That would require management "speccing it out" (ie. knowing what they're asking for).

The only fix for that problem is replace management, which would have to be done ... by management.

You're just suggesting management should follow a waterfall PM structure.

We're supposed to get incomplete specs, it's the only way everyone can end up happy. It doesn't help pointing fingers at an ephemeral 'management' for not knowing exactly how an app should work up front.

Incomplete in terms of technical architecture perhaps, but what ends up happening is that it's very incomplete in terms of function as well.

In fact, it's usually overspecced in terms of technical architecture and woefully underspecced in terms of function.

> You get what you pay for.

It is more than that - it takes an incredible amount of time and effort to setup a good offshore team.

It took my current company over a decade to get to a point where we can consistently get ~10% lower project costs.

That’s a decade of failed and delayed projects! And we weren’t trying to go with the cheapest devs.

When your dev spend is a few hundred million or more a year this makes sense.

However, many many smaller companies have been burned. A couple of failed projects can sink these smaller companies.

i hope this isn’t related to the developer portal.

> In every single time, management outsourced and took the bid from the lowest priced company.

Turns out good engineers make good money. I've worked with some brilliant engineers from India-based consulting teams, and they were not cheap.

I've worked with tremendously good Indian engineers as well. But in most cases they were already in the U.S. on some kind of visa, permanent residents or citizens.

I have had good experiences with outsourcing in India itself as well, there are some serious teams there too. But there were some bad cases as well.

Money is definitely an indicator of quality, expensive might not mean good but cheap almost always means they're not top talent.

This is exactly right , I feel like a lot of problems mentioned in this thread are a result of hiring the cheapest engineer/developer/etc.

Yes, exactly. The problem is that for many companies that decide to outsource, the motivating factor is cost savings. "Why pay $80-100/hr for an Indian engineer when I can pay $20?"

And then six months down the road, "why are all our systems so shoddy?" "Why are our development cycles so long?"

As a consultant, I've seen this pattern so many times it's insane. And depressing... and for better or worse, lucrative.

Paying more doesn't guarantee this. Lots of new developers want those top rates and deliver the same sub standard quality. On the other end, expensive consultants can be highly ineffective.

An HR manager once said each hire is a compromise in some way because no two candidates are alike.

One key in hiring remote is to take some extra time to get to know the candidates via video calls to create a connection and better determine what their strengths and weaknesses are, and get the conversation to a point where the compromise is acknowledged and you can talk about their ability to learn what they don't know and examples of that.

How effectively a developer can learn and apply new knowledge is they main thing I look for. Learning while you work is the new norm, but hiring is not always setup that way.

I don't buy it, easy to blame developers. Why not blame poor communication and specs?

To work with many offshore firms, the “specs” part is a nightmare. The specs might as well be code because common sense isn’t generally so common. For example, sending a forgot password email: actual question: “Should the email go to the email address in the user’s record?” Multiply that by layers of “project managers” and over and over, that means that $35 per hour costs 3 times as much yet yielding a quality level that wasn’t $105 per hour worth.

As several people have mentioned, quality doesn't come cheap.

At the same time, its interesting how broken this ecosystem is (despite the presence of several players vetting these 'companies').

My best suggestion: talk to Indian devs you know (and respect) and ask them for referrals of people back home.

> In every single time, management outsourced and took the bid from the lowest priced company.

What was the initial bid of the Indian company that ended up costing $6 million dollars?

Stories like these make my blood boil. And to be fair it's not just Indian companies. There are plenty of EU/US based dev teams that consistently fail to deliver and the company still keeps paying them.

I wonder if management just can't deal with sunken costs or if someone is trying to steal money from their own company by making under-the-table deals with the development team.

I've had a couple of clients that dealt with "cheap" teams and wasted years of their life trying to get a product up and running. Taking them on felt like rescuing abused puppies from a shelter. Their eyes would light up every time they witnessed a working feature, no matter how simple it was.

That's par for the course when going for the cheapest bid, quality be damned, be it a local company or not. It's just that no local company in a richer country can compete on price, so the cheapest ones went away when globalization got going.

Most companies know one can't hire the cheapest job applicant, they try (more or less successfully) to vet them, yet somehow outsourcing companies are exempt. One wonders how much these managers actually want the project to succeed.

Telstra, Australia's largest telecommunications provider did something similar many years ago. They had to spent X times more and hire locals to fix the code.

This is just bad engineering and project management on Telstra's part.

They should have regularly reviewed the work that was being done and if they had issues resolved them during the warranty period.

5 years back , I wanted to buy a pair of good headphones. Ended up buying cheap headphones made in a country which broke in few months. After buying 3 cheap headphones I ended up buying quality one which was 4 times expensive and have never regretted that decision.

Sorry to hear about your ordeal. With my experience of working from both sides of the table, I can say for sure that you get what you pay for. Quality is not cheap. Companies in the west usually think that outsourcing to Asia and Eastern Europe would mean they can hire slave labor and pay peanuts for work that would cost an arm and a leg back home. As I said, you get what you pay for.

I am working with clients in the US, Europe and Australia. I know my limitations and never bid for work that me, or my team, can't deliver. This is why I have clients giving repeat work since last 7-8 years.

I can empathise with the experience, and have seen many others go through the same.

Part of it is because many colleges(and by extension, firms) in India are focused on knowledge of frameworks and languages as a key indicator of skill and quality. Many, but not all. Which essentially means that, developers are hired cos they know X framework or Y language. When clients ask for devs, how do they choose? Based on skills. Now, when quality is measured not by simplicity but complexity, everything will be over engineered.

An issue that comes up is the without detailed specs, communication and project management skills, any development project will fall off the rails.

Many horror stories are caused by prematurely trying to go fast and making a bigger mess, not knowing how to design, specify, or oversee the building of software.

Overseas is as good as the garbage you can buy locally, but the problems get worse with the distance, time zone, and other things.

how to get these projects? how did the outsourcing company contacted you/management? where did the bidding happened?(upwork/freelancer/companies own bidding site)

I am amazed that low cost outsourcing companies are able to fetch millions of dollars worth of contracts while actual competent developers have hard time landing them.

I lead an offshore development team, I would not hire my team for any kind of development work, you are right :))

You still haven't mentioned the country.


I find a lot of developers seriously lack a professional mentality (I think I'm guilty of this in my youth though I made up for it in dedication and sheer hard work.)

Moving towards the business side I hired a lot of interns from commerce/marketing and they made my devs seem like little babies, it was shocking how capable, committed, team-oriented they were. It changed my view of things.

It's a matter of culture and perspective, and of course the fact that there is definitely such a thing as 'bad management' ... but Engs do have a tendency to think they know what's best for the product roadmap, and have really strong views about all sorts of things.

Some of this is good, in a way, but I really wish somehow the culture of development could be professionalized, both in terms of general approach to working at a company - but also in terms of the artisanal aspects of development itself.

It's important to set tone and expecations early, with smaller units it might work ... but as Eng teams get big, then they always end up reporting to Eng and not product, so it really depends on the culture that the VP Eng / CTO has established.

I would say that many developers often sweat about minute technical details but completely ignore business goals. I'm involved in the local dev community and after meetups we often go for drinks. You almost never hear people talking about their company's successes, growth, strategy etc. It's all about the new hot tech they've recently had a chance to use. This mentality is reflected in the way they carry themselves and make development related decisions.

> completely ignore business goals

Well, if they are not implicated in the business side of things, I don't see how they could be interested in. For example in my case, we're just getting feature requests for the next version, with no indication of business goals.

Because it's self selecting, if your more interested growth and business strategy it's unlikely you would become a developer.

Thank you; a concise way of articulating what I had to write 10 paragraphs (below) to say.

Are developers really allowed to to think about business?

What are some specific (behavioral) examples of "lacking professional mentality"?

+ A general disregard for any activity that isn't specifically development. Like 'meetings'. Of course meetings can be overdone, but they can have a lot of value even if the topic being discussed at any moment isn't hyper-relevant to the developer himself. There's a commenter below who said he has a dev who'll bring in competitive offers if he's asked to go to more than two meetings a week for example. This dev has his 'teamwork' hat on upside down. Sometimes you need teamwork to focus on hyper specific issues. It may seem wasteful often it's not.

+ A general disregard for the talents and value of other groups. (Funniest example: 'ice cream day' at work and these devs cam to sit by us just as we were sitting down and a dev sneers: "Ugh, marketing". We just laughed.) Eng. talent is more classically academic, and yes, marketing is full of fluff, but good marketing, operations, finance is really hard. Basically an intellectual condescension that bleeds into a lot of things.

+ Failing to internalize that ultimately, they work for a business. Sometimes that means doing a lot of things an Eng would never do, like bolt-ons or weird add-ons to address specific customer needs. Cringing around metrics or optimizations that are ROI oriented and maybe not perfectly suited to their vision of what a 'good product' should be. This one can be a real problem in terms of attitude ... because they can get rally angry and stuffy. It's almost an existential debate over who really 'owns' the product in a sense - the business, or the people 'making it'? It really bothers me sometimes the cynical take that many Engineers have in this area - because the presumption is that 'they know better' or 'it's their thing' but really it's not at all. Basically, their view of 'raison d'etre' is often upside down. It depends on the organization.

+ Engs without management experience have a disrespect for how hard management actually is ... more so than in other groups. Marketing specialists are generally not like that.

+ Getting caught up in ideological wars about architecture, or 'bike shedding' - we're all guilty of this, but it's funny how ridiculous and perverse this is when you step outside of it. We're 'building something' not making some kind of 'functional art'. As techies we all love 'new toys' so this one is more understandable.

+ On the business side, if I ask staffers to get something figured out, to give me a quick analysis, to make some slides for the Veep, if they are good, they'll nail it down and move forward. On the dev side, if they even move to it, I get a lot of academic prose as though they don't know the language of business.

It's almost as though it's a little existential: so many on the business side play on 'sports teams' etc. are are very extroverted and team oriented, confident, and natural communicators. Often devs are not. So there's almost a natural cultural clash as well.

You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'. They show up early, bang stuff out, realize that the world is somewhat political, that nothing is perfect, that we have to bend for customers, we do 'what needs to be done'.

Edit: hugely generalizing here. Everyone and every team is different.

Re-reading it I make it seems like devs are this terrible bunch! Not at all, most of this is subtle, it's nuanced, it's not like we have gross dereliction, just some different patterns of culture and behaviour.

I think many of these issues are caused by a "silo" mentality. Decisions often flow from the business end through product before finally ending up as a story in the developers backlog.

How can the devs understand the business decisions and learn to make less academic slides if they are not exposed to the business?

I worked at a medium sized business where devs had lunch with sales/product/marketing and was treated as more than just coders. That has helped me a lot when it comes to the business side of work.

If you have problems with the developers in your company, it may be that the real problem is with the company culture.

I agree with your points about exposure - however - these problems generally do not exist in other parts of organizations.

Devs are unique in their peculiar aspect disdain for 'management and business'.

And unfortunately it's very rare that devs get such exposure but we agree it'd be great if they could.

Have you considered that the disdain comes from not being treated with respect?

I don't know what comes first.

But the places where engineers get on well with management are the ones where their opinions matter. Otherwise resentment comes in.

Devs are unique but I would argue it's less of the dev mentality and more about how management and business can incorporate them as part of the decision-making process.

Granted technical folk are a special breed but being technical myself and having moved over to the business side of things, it's still equally important to think about motivation for devs.

To maintain engagement, I bring my technical guys with me to meetings where they can add value. And I always press about the value of meetings and what we're trying to get out of it.

"...You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'.

Yeah, and this is exactly the kind of person that gets laid off first. You have to be a little bit of an asshole to survive. Have an "edge", even if it works against the company, so you are perceived as a "badass".

Your list resonates with me on all points. Sadly, it seems that due to scarcity in the market some engineers are acting like self entitled, spoiled babies. The arrogant/know-it-all streak on topics way outside their area is also pretty pervasive. It changes with age though. I was like this 10 years ago to some degree. You mellow out over the years.

I think this can also depend a lot on whom you hire. If you make that a screening criterion, it’s not all that difficult to assemble an engineering team entirely of people who understand business goals, can communicate with non-technical types, and recognize the value of other fields and departments.

Being a dev myself I 100% agree with this.

I think that you make a lot of very good points. I have also seen self-entitled, arrogant developers stomping around like they own the place, not respecting the difficulties in different roles (management) or other disciplines. I've seen endless bike-shedding, and endless toy-chasing (at the direct expense of the business).

But I also think that there are some significant problems in what you've said.

You describe what looks like a siloed structure, where sales/marketing people are deciding on what to build, and then throwing it over the fence to the developers to just "get on with". Where are the fast iterations, looping frequently back to the customer, and involving the whole team in the process? Does a developer never have a good idea with regards to features? I think that if you want robots who do what exactly they're told, then you're going to end up with... a development staff of robots.

Meetings. Endless meetings. Agile, if done on a weekly cycle, gives you no fewer than seven mandatory meetings. I don't disagree that it's important to communicate, but the prevailing culture across the industry is absolutely towards superfluous meetings which involve too many people. And I think that's a big problem. Yes, developers need to understand that perhaps not all of a meeting will be relevant to them, but if they're not relevant to the meeting, then really they shouldn't be in it.

"Failing to internalize that ultimately, they work for a business." - I think that the above point on solied structures is relevant here, but I think that there is more also. It depends on the type of business, and I think that you're referring to B2B. But I have personally seen in the B2C case, with millions of users, the sales and marketing side - sometimes from different divisions - preference their own career objectives over the user's experience. "We sold this for a million dollars" "But there's spyware on the partner side sometimes" "Tough. Build the integration". So while I think that you're right when it comes to building a special-case for a particular customer who genuinely needs that special case, I think that there are also other cases here where it's not that simple.

A more minor point but when you say "as though they don't know the language of business", I think you're right, they don't know the language of business!

I find your sports team / jocks vs nerds analogy interesting, perhaps mostly to inform on your general perspective. Personally I would prefer a team of smart developers who care deeply about the product that they build, working hand-in-hand with the product team, designers, sales, and customer in short iterations where rather than deciding precisely what will be built up-front, the solution is instead found organically with valuable contributions from everyone.

But you're dead right on the 'new toys'. That practice is unforgivable.

1. Undocumented server setups with passwords saved in their own password manager and refusing to hand passwords and proccess after being fired.

2. Hacking the servers after being fired and deleting the data

3. Insulting the guy from the marketing/sales/customer service department for lack of technical knowledge.

4. Asking the woman from the customer service department to be a cheerleader to up his motivation while he fixed the customer's problem.

> 1. Undocumented server setups with passwords saved in their own password manager and refusing to hand passwords and proccess after being fired.

That's as much a management issue as a developer one. There's no way the developer should have had sole power in the first place.

I mean, I get it. In a previous life I was "the IT guy" with absolute control over my domain. But I'd have hoped most organisations would have wised up nowadays.

> 2. Hacking the servers after being fired and deleting the data

If true, that is a pretty easy prosecutable criminal offense. Did you press charges?

>2. Hacking the servers after being fired and deleting the data

May I ask what happened with this?

For many companies step one would be to contact the feds, and then the former employee would awaken to the sound of their door being kicked in pursuant to a search warrant for all of their personal devices.

Why is this a federal crime?

>Why is this a federal crime?

Anything related to damaging computer systems via way of unauthorized (or even sometimes even authorized) access can easily become a federal crime.

The CFAA[0] comes to mind, see 18 U.S.C. § 1030(a)(5)(A).

Moreover, the feds are typically better equipped than local jurisdictions to handle computer-related crimes.

[0] https://www.law.cornell.edu/uscode/text/18/1030


Mine wanted to get paid. Can you imagine it? Building the best product ever just wasn't enough.

P45's all round and the issue was solved, permanently.

For non-UK readers: according to Wikipedia, P45 is slang for firing an employee.

Yep - in reality it's the number/code of the HMRC (tax authority) form you get when you leave a job.

Thanks... so kind of like how we would say 'pink slip' in the US.

A P45 is the official document you receive when you leave employment (fired or not), it isn’t slang for anything though you may be threatened with a P45

"The term is used in British slang as a metonym for termination of employment." [1]

[1] https://en.wikipedia.org/wiki/P45_(tax)

You seem to be telling someone who lives in London how British slang is used because you read about it a few minutes before on Wikipedia.

Fellow Brit here. Born, bred and then f'd off elsewhere. I'd argue P45 is slang for being fired.

Its slang because P45 has nothing directly to do with being fired. It is a tax document related to changing employment.

I agree (born and live in London). I've never heard P45 used as slang, maybe you could use "given a P45" to suggest someone was fired though.

Something to do with acquiring a P45 as a noun, yes. P45 isn't itself a verb that means firing as I infer the OP to be saying.

So you didn't pay them?

I'm pretty sure this post is sarcastic.

Ahh I see now. Sarcasm isn't always obvious in text form.

Developer attitude towards spending money on software...

"Invented Here Syndrome" when it comes to the choice between writing 50 lines of code vs. pulling in 4mb of client side dependencies to use a giant 3rd party (yet Open Source and therefore Free!) library that incidentally offers a solution to the same problem, after about 50 lines of configuration.


"Not Invented Here Syndrome" for anything that involves paying money for anything. Such as that API that solves the exact problem that's blocking us from moving forward, offered by a company that does nothing but solve that problem for a living, because we might outgrow their Free Tier and therefore face potentially thousands of dollars of charges. Argued among half a dozen market-rate developers of a venture funded startup that could really do with having launched yesterday. Rather, let's pause to build our own version of that service first. Then build our product.

I tend to notice these things while working as a consultant, and thus something of a bystander in terms of being able to do anything about it.

This. Developers often have a blind side to their own cost and will happily spend a week or more of their time (i.e. a few k$ at market rate) to shave $300 from an AWS bill.

They should start a business. Then they’ll realize how valuable their time really is and that $100/mo won’t seem so bad. (Note: I’m an eng who used to enjoy reinventing the wheel.)

This is hilarious and completely nails a former coworker and engineering manager of mine. Morbidly afraid of paying $10 for any service.

I have worked in software for 20 years with numerous being very early stage ventures. I would say that most of the problems I’ve faced in software venture is with non-technical founders who, generally speaking, provide minimal value until product-market fit is achieved. This sounds like the kind of question I might have faced in those ventures. If it’s a software venture and the founder is not either a skilled designer, talented product manager, or a developer working very closely together, it’s very unlikely to succeed. Perhaps a better question is “Developers, what is the worst experience you have had with a non-technical founder?”

Our Android developer silently inserted cryptocurrency mining code into the new release, pushed the clean version to github, but submitted the infected version to Google Play.

After a few weeks Google caught that and banned our app. We lost thousands of customers and years of work and had to start over with a brand new app. Years later the infected app is still mining cryptocurrency because users ignore Google’s malware warning message and keep using the app.

PS: I should have said “our FORMER Android developer.”

That is truly terrible! I hope you took legal action and are still garnishing that man's wages to this very day.

Damn, I wonder what that kids childhood was like to form that kind of dishonest person.

Could someone explain to me why this question has gotten so many upvotes? Are bad experiences with developers common?

My impression is that most of the time perceived bad experiences with developers comes from being a bad manager.

Your view might be from spending lots of time on HN and around engineers? I spend time with both, and I can see issues on both sides.

From the business side, here are examples I've seen:

- Have to use this technology, everything else is old, anachronistic, and unperformant

- System has to be scaled this way from the start (in startups, often, no it doesn't)

- Tension in how you trade off new features with clean code (there's a balance, and each environment requires a diff tradeoff)

- Building feature a certain way because it's easier for them, while ignoring what's appropriate for the customer/user

- Unwillingness or inability to explain technical topics to non-technical audience

- Making decisions solely on technical appropriateness, rather than broader appropriateness for the company (say, availability of other engineers to work on it)

There's lots on the managerial and business side too, but I'll save that for another thread.

P.S. A favorite quote of mine from Chinua Achebe (old proverb): Until the lions have their own historians, the history of the hunt will always glorify the hunter.

Any group we spend our time around will show itself in a good light. Even more so when we are a member of that group.

It can go both ways. I have seen bad management and I have seen bad engineers. "Bad" meaning hard to work with in this context. Usually the bad behavior I see from engineers is arguing pedantically every little point, not doing the paperwork, unilaterally deciding a feature should be implemented differently just because it is easier for them even though it hurts the product or business. Stuff like that.

This. People leave managers they don’t leave jobs. But... people can wear many hats but regardless of the hat can still be jerks.

No developers are often terrible.

Source: developer

I can't tell if there is a comma missing or you really mean that noone is terrible?

With the ubiquity of smartphone keyboards (I'm guessing), I've noticed a major trend toward zero punctuation, especially commas. You have to learn to just add them yourself, kind of like how a Javascript interpreter automatically inserts semicolons for you.

However, comma placement can usually change the semantics of a sentence. Thus you can find yourself guessing the wrong meaning.


Most devs have no management experience and it's like trying to describe what 'drunk or high' means to someone who has never had a drink or smoked up.

It's trivially easy to 'blame management'.

It's often the case, but it's often not either.

I had a boss once who conjectured that when you point a finger, there are three pointed back at yourself. I often come in to "rescue" projects after an initial developer or team, and more often than not I find just as many mistakes on the management side. For example - if the developer(s) have set up the production environment using their own personal AWS account, or set up DNS in their own name, yes, they screwed up, but that's the company's IP that management has failed to secure. Problems go both ways.

If developers did that against original requests, that's a huge problem and the dev is at fault.

If, as I've sometimes seen, the dev asks for credentials, and a founder doesn't do it, or continually ignores the requests, but pushes for 'get it live', falling back to personal credentials (with reimbursement or using a company card) is a not-unusual fallback.

If, after it's done, requests for transfer to a 'company account' are not made, again, dev at fault. If requests are made, but not granted, owner's fault.

I've seen multiple scenarios happen, and they've gone in all directions.

We operate in a completely unregulated environment, where anyone can hang out their shingle, calling themselves a software developer. For that matter, even our CS programs are not really training people for careers as software developers. Thus, there is a huge spectrum of training, experience, and talent in what constitutes software development. But, what I've witnessed is that as the "software is eating the world" mentality has taken off, in many companies responsibility for everything about the software has been delegated downward (shit rolls downhill) to developers who are not product managers, not security experts, not database experts, not really anything except <$lang> developers and then the company is surprised when in the absence of support and resources, they resort to just get it done techniques.

I hate how whenever I ask them to attend more than two or three meetings a week they start showing up with competing offers.

Now I let them invite me to meetings when they think I'll add value, usually by talking through the product roadmap and business metrics.

The workaround is to get a gang of people around a desk chatting with a line of code up. Its no longer a meeting, but you can slip in some "how we tracking on the deadlines" type questions.

The first line feels sarcastic, but the second one is as sensible as it can get. I'm confused :P

Was working with a developer through Upwork who claimed to be from Japan. Was in fact from China. Upwork terminated their account without warning, and we owed the individual money. Was a legal and logistical pain in the ass. I guess this is a bad experience with Upwork as much as with a developer.

I came into a project where I quickly realized the 2 upwork developers was just 1 dude who decided he could double his pay. Management was asleep at the wheel.

If a company does this its called "growth". An employee? "fraud".

It's hard to know how to apply the appropriate 'grain of salt' when reading things like this thread. I worked for a small (~40 person) start-up before where there was rampant religious discrimination and inappropriate workplace behavior by executives, even the head of HR who functioned more like a culture gatekeeper to enforce the particular overt religious cultural aspects of the founder.

When developers pushed back, they were called uncooperative, threatened with pay cuts or being fired, told they were not team players or were making too big a deal out of things. It was crazy!

In my experience, the times when management believe they are suffering from a problem developer are actually reflections of the management. There are exceptions like employee theft, issues with employees after they are terminated, and these things are often pretty black and white. But for all the other types of things that are more subjective about effort or cultural fit or finger pointing or tone or attitude or whatever, I tend to think most employees are absolutely not the problem, rather it is inept management and extremely poor culture mandates.

I disagree. Both sides can have issues, and it's not primarily the fault of "managers." You can see some issues that I list elsewhere in this thread.

The part I do agree with is that responsibility to address the issues often is in management.

I do wonder if every tribe thinks they're good, and it's the other side at fault? ... I think about this a lot in my media literacy work, where I explore the empathy gap:



Both sides can definitely have problems. But I think there are severe asymmetries at work, like what is chronicled in Moral Mazes. There is a big asymmetry about how managers and executives think the world is supposed to work for them, vs. what is a realistic compromise between complex teams that have to coordinate. Executive or management bad behavior can be hidden, papered over, politically rewritten, etc. etc., while executive opinions about the behavior of subordinates is often taken as unquestionably 'morally' right within the context of the morals and ethical systems that evolve inside a specific corporate hierarchy.

I think as an abstract sociology problem, there is every reason to believe the dynamics of the situation make it far more likely to be problems with management or executives, and that it ought to require extraordinary evidence to overturn that prior point of view and instead believe it's sincerely an attitude / effort / tone / culture fit sort of problem on behalf of employees.

This isn't really special to companies where employees are developers. It's just a general property of the phenomenon of a corporation, period.

I’m not a founder, but I think it is not about developers, but rather about personalities (read same things happen everywhere). So, for me the worst things I saw: Pure incompetence mixed with arrogance Bad temper - impossible to argue without getting yell at Chronically ignoring mission and goals (read like doing things they like vs what is needed) Slacking and lying about it Lying in general (work, travel, etc) Psychopathic beghaviours

So, in all those cases, I believe, the only way is to say thank you and let go.

And i’m IC

We had a developer who worked on one of our projects. After he left, it was a disaster. Our new developers discovered that the names and items he used were strange and not related to what it should do. So the devs needed to go through all codes, figure out what it's doing and rename the code. It took a lot of time...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact