Hacker News new | past | comments | ask | show | jobs | submit login
Be likeable or get fired (sites.google.com)
420 points by gnulinux on Apr 20, 2018 | hide | past | web | favorite | 320 comments



Some hard lesson's i've realized while working in "professional" environments:

1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier.

2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around.

You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit.

Or you can just start your own company and make your own rules.


This is key. I see that there are two aspects of this story:

1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process.

2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge.

That said, I agree that it was better for him to leave.


> Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months.

Well, he sucked in that team. It's good to know the kind of person you are. I've learned, somewhat the hard way, that I become a bit of a nightmare in situations where I can't make a difference quickly. This tends to lead me away from very large, very process-driven, very political organisations, because I simply don't have the temperament for it, and towards smaller, scrappier companies, where it's possible to make forward progress quickly.

One day, after all, I will die. I don't want to have spent too much time between now and then having to deal with torrents of organisational bullshit. The fact that I don't know how much time I have left only adds impetus to cut through the nonsense.

Whereas some people can survive, and indeed thrive, in that kind of environment. They have the patience to see it through, and gain their satisfaction in other ways than merely seeing the product taking shape quickly.


What clarified things for me while reading it was coming across this line:

> Well, I AM actually stubborn!! But if the metrics had shown that BATCH was worse, I would absolutely be the first to change my mind.

He's self-critical. I also think he's only right about being stubborn in its original meaning (untameable) rather than the new colour the word seems to have (unwilling to change despite evidence).

What happened here was an NHL player joined a team thinking it was another major league team, but it wasn't even college ice. That's fine, but his mistake was not just leaving for a different team. If you come into a team thats slightly beneath you you can raise it up to your level and change peoples careers / lives for the better, but getting too far off just doesn't work. You're way too ahead of them and you're new so they don't trust you or want to listen to you. Just move on to a more pro project.


Exactly, I remember this stellar test lead was hired by a previous company I was at. Once he was on the ground And saw the state of affairs he resigned and said this company isn't ready for him. We an org is running too crudely you can take a professional hit working on structuring things that don't stretch you professionally. To stick around in a technically immature environment can cost you.


Right. OP was providing leadership. Sometimes that means stepping on others' toes, and how they react is key. That team was a problem anyways.


That's not what leadership means, unfortunately. Being right in a non-productive way is also a failure in leadership.

At the end of the day, if you do want to provide technical leadership, the skills to understand the team and how to interact with them effectively are at least as important as the technical skills.


If you cant achieve change, camt negotiate and cant explain, you are not providing leadership. Regardless of whether you are right.


Maybe that's the problem; he wasn't hired or looked to as a leader, or as previous commentators have said, he hadn't earned the respect of the team yet.


Its often very common that those with the best insights into improving a system also have the least power / knowledge of how to pull levers of power.


I mean that's not particularly surprising, since someone who both had the insights into how to improve a system and also the knowledge and power to change that same system (and who cares) will generally make those improvements. So if you see a broken system, and someone who knows how to fix it, and that person is not fixing it, there must be something (organizational badness, higher priority fires elsewhere, apathy, etc.) blocking them from fixing it.


Very well put. It's like how hard/right decisions are "difficult" decisions to make. If the right decision is easy, everyone makes it without too much consideration. If the decision is hard and wrong, no one would opt for it.


Currently I'm the "surviving senior dev" for a very old crufty mission-critical legacy app, and I'm painfully aware how broken it is and the ways in which is breaks.

So sometimes I have to kindly remind myself that its current state isn't indicative of some damning (yet oddly egotistical) personal failure, where I "shoulda" rewritten everything from scratch by now.

On the plus side, the QA team is gradually learning to do more than manual browser tests...


So the way you see it, the people who have the power to fix things do actually fix everything they know how to fix. So then over time the situation stabilizes around people who have the power to fix, but everything that remains is beyond their insight. Anyone who has the insight is a relatively powerless newcomer.


Yes, pretty much. Well, newcomer or someone who just learned something new.


Maybe we only hear about their frustration precisely because they don’t have the power to change things. “Leadership changed things for the better” isn’t much of a headline, it’s the expected/desired outcome.


This is exactly why it's so valuable to keep good notes while onboarding a new engineer... A fresh set of eyes gives you a rare opportunity to see problems that familiarity has blinded you to -- yet a new engineer is in the worst position to fix these problems.


I don't think his expectations were unreasonable and I don't blame him for not wanting to spend years of his life slowly trying to fix a dysfunctional team/process. I know it's not easy, but companies should do a better job at hiring so that both parties time isn't wasted.


Why do you assume he sucks working in a team and that the other team members were not the issue?


Honestly? Because the whole article reads like it was written by the sort of socially oblivious person who doesn't work well in a team.


When everyone else appears to be the issue, perhaps it's worth considering one other possibility...

There's something about the writing style on that page too. Hard to describe.


"If you encounter three jerks in one day, you're the jerk."


Community of jerks usually easily accept another jerks, so it's quite possible to find yourself among jerks even if you're not jerk.


Ha! You've never worked as an air traffic controller. That job attracts type-A personality jerks like honey attracts flies. I've met dozens of jerks at one time. And not a single one of them would call me a jerk. Okay, maybe one or two of them would. It's such a toxic environment—I had to resign.


He's obviously not a team player!

(I'm totally kidding; your question is an excellent one.)

What's funny to me is how sometimes there are two qualities -- being both more competent (than one's peers) and not liked -- that in combination can further perceptions that someone "isn't a team player"..in the eyes of The Majority, the same people who are the real problem.

If the team says pigs can fly, the sky is red and Bob isn't a team player, all of those things might as well be true. After all, perception is reality.


A team has its dynamics. It is difficult to join a team if you have a self assigned mission from the get go. The author seemed to have done that.

The author was also smarter before he was empathetic. When he saw someone become touched after the criticism he put forth, he should have changed pace. And changed focus. Instead of focusing on the critiques, he could have focused on the outlying problems contributing to those critiques.

Instead of ignoring the responses everyone made to good suggestions, he could have been more accepting and started to beat the same drum.

Point is to find common ground first. Solutions come second.


I will add that, as a new employee, the best possible way to gain the trust of your new managers is to make them look good. In the case where you can see some obvious improvements, that means working collaboratively with the manager so that they can take some credit for the improvements. Specifically it means offering criticism and suggestions privately, getting the OK before making changes, and letting the leader manage the broader communication about the changes.

This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above:

> Or you can just start your own company and make your own rules.

When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that.

In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them.

If they are total assholes, you don't want to work there anyway.

But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.


Code ability != leadership.

Being alpha geek and able to code well doesn't correlate at all with the kind of management and people skills required to run a team. There's a ton of Daily WTF as examples of team "leaders" who are great coders but cannot communicate at all.

The standard MBA solution for this situation is the "surgeon model" used by medical teams. The tech lead makes all the technical decisions, but there's a team leader or manager who makes all the leadership decisions, and does the "people stuff".

That "people stuff" totally includes firing team members who the technical lead doesn't like, for whatever reason.


i'm not sure how you arrived at the "surgeon model" being the "standard MBA solution".

my mba program emphasized that (1) effective teams can be built from a diverse variety of people and organized in many different ways, and (2) the effectiveness of the team rests on trust and honest communication between team members (technical skill is rarely the limiting factor of a team).


I never had a good result from making too bold suggestions too soon. That could actually stunt my career for years. I've had much better results from making it clear that I respect my coworkers, and finding things about the system to compliment, regardless of my opinion of the overall quality or design. Nobody around me needs to hear that I think the system they made is net sub-optimal in some general sense.


Excellent points. Often those at the top have gotten where they are because they are good at making others appear less competent and themselves appear superior, regardless of the actual truth. The last thing you want such a person to think is that you are on a level where you might one day be in competition with them. You have to hide your power level or these people will campaign against you by creating the perception that you are inept or difficult. The best strategy in these situations is to follow their directions exactly as instructed and privately broadcast your abilities to others in the organization in such a way as to avoid detection by the inept manager.


> It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge.

Also worth pointing out: Sometimes (often) the people who are most vocal about this are not the best coders :-)


Also worth pointing out: the people most comfortable with complexity often “rise to the top”, and they are not your best coders either.


Whoah, there. Some people are extremely comfortable with complexity and yet are still zealous about simplicity and elegance.


Haha. Some. That's the joke. Would that "some" were there much earlier in the product I work on...


> You have to realize a team that's been there before you has done things in certain ways for certain reasons

This is a fundamental insight that a lot of people don’t seem to get. I always refer to this quote to drive home the same point: “There is no such thing as a dysfunctional system, because every system is perfectly aligned to achieve the results it currently gets.”


Sometimes those reasons, unfortunately, do have to do with the fact that they are actual imbeciles.

If you want to be likeable among imbeciles, then you have to emulate one. When in Rome and all that.


When developing and documenting systems, I find it's really important to document Why you are doing things a certain way. What is done, and how its done can often be discerned from looking at the current implementation, but why needs to be explicitly documented.


This is what I think every time I see the JavaScript programmers on HN critiquing SpaceX or other aerospace system designs from their swivel chairs.


"Excuses for why shitty code is in production are probably legitimate excuses"

Honestly, I don't think this is true in the general case. It's certainly true that there are times when deadlines mean code quality is going to suffer, but I think the incidence of this is probably lower than the frequency with which this is used as an excuse.


In my experience it is almost always the case. I think this is a case where Dunning-Kruger* often applies, which is to say that you enter this new environment and think you know what's going on only because you're so completely ignorant of the details. Other times it's simply that decisions were made that made sense at the time and only look stupid with the benefit of hindsight. In either case, that bad code probably still exists in production for a very legitimate reason: the trouble it causes isn't worth the cost to fix it.

*I'm aware that DK doesn't really say what the common interpretation says it does


Another concept that complements this is the fundamental attribution error. It's called that for a reason. Instead of first assuming that everyone who came before was a terrible coder/worker/person, you have to look at the context and incentives at play.


I find the common cause of bad code is changing requirements. If someone is given the choice of a change that takes 1 hour or 1 week it's very hard to stick with clean code. Make a change and then undo it more than once, and it's easy to leave a few if (false) bits hanging around that don't break anything today.

Next biggest issue is a changing team. If you don't really understand some bit of code it's often safer to code around it than mess with it.


If the code works and produces money for the company, no excuse is needed.

Perhaps the founder had better things for his time than perfecting some code that was already good enough to get clients/VC money.


That attitude makes sense, initially.

But continuing to ignore code quality (and potential security issues) and blindly piling on complexity and feature creep and hoping for the best is just playing Russian roulette with your money.


If the company expects continuing maintenance and feature additions to that same code, then yes, a better excuse is needed.


Sure. But they can pay someone to fix their mess when that time comes.

It's a "nice problem to have" kind of thing.


There is no general answer. In any given case, you don't know.

Just you would like for people to assume you have the best intentions and reasonable practices, you should also provide some respect to the developers of the original code and not assume what you see in production is necessarily their best work or the way they would do things now.


Your #1 is so true. The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen.

Now I just put a mental crosshair on the code I want changed and come back to it.


> The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen.

The number of times I've spotted some terrible bit of code then go through the version control system to try to find out more of why that moron did what he did only to discover that I wrote the code is embarrassingly large.


Ditto. Not only that, but when working with a large codebase, design decisions that seem unfathomable at first glance often turn out to be reasonable or necessary once you understand the code and its use cases.


I think people mistake the source of frustration. It’s not that the other guy took on tech debt. It’s that he kept saying “we’ll fix that later” and never did. Corner cutting isn’t fatal. Often it’s not even all that painful, if I’m perfectly honest.

It’s the delusion that hurts.


In my experience, the person adding the technical debt usually had every intention of going back to fix it, but they were never given the time to actually do it. :)


The road to hell is paved with good intentions. That's the delusional part of the problem. You won't look at it because admitting you have a problem is the hardest part. "I'll do it later." is the primary failure mode we have for personal improvement across just about everything. Diet, personal finance, interpersonal relationships. There's a whole category of aphorisms dedicated to this.

Nobody is going to schedule time for integrity on the project roadmap. That's not how integrity works. You can find some or lose some, but on any given day you have it or you don't.


But "technical debt" may also means he didn't do it in your preferred way. This double meaning really bothers me. It's like technical debt.


I’ve become more aware (again?) lately of the differences between ugly code and debtful code.

When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory. You pingpng around and when you find the problem you can’t remember why you were looking for it.

Then there’s code where you say “ugh”, take a breath and keep going.

If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues.

That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.


The idiom that always comes to mind for me is "good fences make good neighbors."

In the long run ugly lines of code are so much better than a broken architecture or too much coupling.


True. If the blast radius is small it only matters if you see the same three lines of code in twenty places.


They aren't just giving in to your tastes?


There are so many things that could go wrong in delivering a piece of code. Just the ones I've seen enough times to build rules of thumb about exceeds my own powers of recall. And some people reliably trip over certain failure modes, while others avoid them subconsciously, never even realizing there was a hazard to begin with.

My new motto is: filter out the reversible decisions and worry about the rest. When something in the former set breaks, make it a teachable moment.


Yes, one must be able to discern between technical debt and taste.


technical debt is not always a "bad thing". Sometimes it makes sense to rapidly iterate until you understand what it is that needs to live on. If the risk for not getting the code out exceeds the risk for whatever technical metric is going to be improved by addressing the technical debt, then by all means iterate.


If technical interest rates are dirt low on your technical debt, go into technical debt. :)


Loved how that was framed. I'm going to start assessing the interest rate. Which to me is the interest leadership has on fixing vs new features.


Or, to stick with the analogy more closely; what is interest? It's the cost of servicing a debt. Technical debt has a low cost to the extent that it Just Works. If it has to be constantly propped up, then it's high interest.


For instance, there is no point in refactoring a piece of code that never needs maintenance. In that case it is good debt and it already paid off.


Cmd + f TODO :shudder:


Hah. And that's probably only 10% of what really needs to be done.


#1 might be common, but surely is symptomatic of something negative. Like fragile egos.


I've luckily managed to pick up on these lessons without learning the hard way.

At my current job, the quality of the codebase is frankly, quite shit. The unit testing coverage is fine, but the actual quality of the code isn't good. It's not clean, there's a lack of separation of concerns, it's poorly formatted.

Within the first week of starting the job, I had a laundry list of things that we should do to clean up the codebase. However, I've been slowly feeding this list to my manager, rather than just dumping it on him.


Forcing a new "unrespected" hire to engage in a broken system is such wasted potential. These are maybe the only people who can change the system for the better. Their unfiltered view can help identify inefficiencies in ways entrenched workers cannot. But instead companies force the most manual, annoying processes no one wants on them, until they are crushed by the weight of status quo and become part of the problem.


There's that saying: if you speak the truth, make them laugh. Otherwise they will kill you.


The ones with no sense of humor will kill you anyway.


Letting new people who don’t thoroughly understand the old system write a new one seems like a recipe for another broken system.


My point is that companies should welcome the feedback, facilitate and encourage it. Not that new people should re-write a new system


I agree completely with this, but getting back to the human factors:

- It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus"

- the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap."

The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."


A lot of times if you say, "I'm having trouble understanding how module X does Y, and why it works that way." And the developer will say, "Yeah, I kind of hacked that together when the requirements changed. In a perfect world, it would get rewritten, but I've had a bunch of other things higher priority."

So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.


Yep.

And then you understand that you weren't wrong, and the opportunity for improvement is there, when time is available, but you haven't risked alienating people by treating them as if they're idiots for writing imperfect code.


For every story like this, though, there are probably 10 where the new hire didn’t know better than everyone else. I know I’ve dealt with plenty of people like that.


How about forcing him or her to articulate why the system is broken with code instead of saying vague things about tech debt?


How about simply asking?


Well of course. I hope no one is actually forcing them, but professionally forcing them is what we're talking about.


> Product managers/sales/marketing do not care about your unit tests

Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it.

It's our job as developers to explain the importance of unit tests, and why they're non-negotiable.

Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).


> It's our job as developers to explain the importance of unit tests, and why they're non-negotiable.

Let me put on a hat that I wore a few times - someone who had one person above him in a company. I will also preface this with 'I hate sloppy code. I hate shortcuts. I want people to spend time on building tooling instead of writing features. If I could wave a magic wand we would have 99% test coverage'.

This is 100% incorrect. Code quality on a list of priorities for the business is somewhere between the taste of a three day old coffee and a french fry that fell off a tray.

Business is there to make money. It means that code that works somehow is better than perfect code which did not happen to ship because developers are still working on the unit tests. Developer time costs money. Operations people time costs money. Anything that does not make money but costs money gets de-prioritized. If you think that "code smell" and "unit tests" are non-negotiable especially if it is at the cost of tweaking/fixing something that is going to generate revenue, you are drawing a line in a sand and I'm going to have to point you at the door.

If you would like to get me to allocate resources ( read: $$ ) to address code smell/code stench/etc, you need to either convince me that the sky is falling ( i.e. we start losing money/we are going to start losing customers ) or you need to give me something that can offset some of my costs or you need to come up with a clever way to enable us to make more money.

> Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).

Exactly. The "right time" may not be now and may not be before. It may also not been for another year.

P.S. Incidentally, this is also why product people/project managers and sales people get a better seat at the table than developers ( which is a mistake, from my perspective ) - they typically talk about money while developers talk about code.


But now you're asking software people to predict long term costs on processes they don't even control, and it's already notoriously impossible for them to do it in the short term on processes they do.

I don't see how you can expect more than "if we don't do it, we'll eventually have problems." Customers might leave and features will get harder to implement. It all costs money, but how much is very difficult to say.


If you cannot qualify your problem then it is not a problem that needs to be addressed.

Let me ask you this - if your car mechanic told you that you need to overhaul your entire car because he did not like the way it felt to him would you let him do it?


Implementing good testing is not an overhaul of your entire business.


In that case you should be able to justify it.


Yes. This is the difference in perspective between a company founded by a technical person (or someone who has a competent technical "right hand") and one founded by a non technical person. A company can succeed for many years, 10+, with a non technical person. At some point the decisions made and the shortcuts will start to catch up.

Having worked on legacy code bases with version control you start to see patterns. While there are definitely those decisions made because they were required at the time there are also definitely those individuals who obviously were out of their depth or were willing to "hack it" to get it to work. And a lot of times, they are lauded as being "A+ top producers" when the reality was they just did it faster than everyone else because they didn't think about long-term quality.

The story version, I see in terms of manufacturing. If I was working with a parts supplier and asked for them to deliver a part I needed. The requirement was as fast as they could do it. They make good on the delivery. From a business perspective everything is great. We're making sales and we met our deadlines. The supplier was great in helping us out. Suddenly three years into our five year warranty parts from the supplier start failing (performance problems and fragile releases). It becomes obvious there's a major quality problem in the parts that were manufactured. We talk to the parts supplier but they've gone insolvent (the software engineer left the company). Suddenly we need to hire a new parts supplier (a new software engineer with years of experience) to rush the replacement parts that are required to meet our warranty. Which, (hopefully) having learned our lesson are paying the higher rate (proper compensation and reasonable time for quality) to guarantee a quality replacement part to prevent the loss of profits of another round of extended warranty replacements. At this point the company has just cost itself both monetarily and potentially in reputation by making the original decision to fast-track production to "get to market".

I recognize that the scenario above isn't software. It's a physical thing that's gone out into the world out of the control of the company that created it. But fundamentally the same trade-off of "deliver it now" vs "deliver it right" is made. And often made by people who don't never consider the long-term costs (technical debt) because "that's not now, that's in the future". And people will often rationalize their decisions in these situations. The often spoken:

Over confidence "That happens to other companies, we'll be successful."

Lack of understanding "I don't care about the outcome, we need it now."

Individual worship "John said we could do it, so we're doing it."

Punting "We'll deal with it once we have slack time."


>> non-negotiable

Sure.


>Or you can just start your own company and make your own rules.

People need to stop saying this.

It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups.

The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things.

Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules".

I wasn't. My runway would have been about 10,000x shorter than his.


>It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups.

Whats the fallacy for when you think you've identified a fallacy and simply assert it? Just because someone writes down the definition of a fallacy doesn't make it true. A dog has four legs and a tail, but its not a cat. Sorry, the fallacy thing is a pet peeve :P

Anyway, back the to topic. I do believe, you missed the central point and latched onto a tangential irrelevant point. The point is identifying the company culture, understanding peoples personalities, their motivations, and then figuring out a way to work together - even if you have an annoying boss, even if your coworkers are incompetent (as they often are), even if you think you know how to fix all problems - is WAY more important than doing something because you think youre hot shit who can prove people wrong.

>The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things.

>Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules".

Okay, but that is not the only way people start companies. SV is its own bubble, when you can funnily enough, become a multimillionaire without turning a single dollar in profit. In the real world people put their savings/health/marriage/family life/ on the line and sacrifice a LOT to start a company.


>Whats the fallacy for when you think you've identified a fallacy and simply assert it?

Not this.

>Anyway, back the to topic. I do believe, you missed the central point and latched onto a tangential irrelevant point. The point is identifying the company culture, understanding peoples personalities, their motivations, and then figuring out a way to work together - even if you have an annoying boss, even if your coworkers are incompetent (as they often are), even if you think you know how to fix all problems - is WAY more important than doing something because you think youre hot shit who can prove people wrong.

There are a few people saying that. Nonetheless, I do believe that there are a number of people on this thread who are happy to use that as an excuse to say "shut the fuck up and kiss the ring" (e.g. the guy who said 'wait six months before proposing anything new'). That isn't healthy either, a and if you work with people like that the healthiest response is to leave and try and find somebody who isn't a jerk to work for.

>Okay, but that is not the only way people start companies.

I didn't say it was. Nonetheless, the most common unifying feature of entrepreneurs isn't a propensity to be trailblazers who take risks - it's access to spare cash, and, shockingly, not every employee of every company has capital just lying around.

If we're talking probabilities, the average entrepreneur is more like my boss than Mark Zuckerberg.

Bosses like to feel that their authority is deserved though, and it's easier to think that if you spread the myth that just "anybody" can start a company.


>e.g. the guy who said 'wait six months before proposing anything new'

>That isn't healthy either, a and if you work with people like that the healthiest response is to leave and try and find somebody who isn't a jerk to work for.

That is a weak point though. The alternative explanation to that is that they didn't actually mean what you think they meant.

It is very tedious to say "wait six months before proposing anything new - but be polite and ask questions, don't be a pushover, don't agree to unethical decisions, don't be a jerk, etc, etc" People often use shorthand to convey their strongest point.

>If we're talking probabilities, the average entrepreneur is more like my boss than Mark Zuckerberg.

If you're talking about finances - totally disagree on that one. There are FAR more small businesses funded by small loans or borrowing from your savings or family, and grinding it out, than being handed million dollar VC cookies. That's my own feeling based on businesses around me (I'm not in SV)

Some quick data that I pulled: https://www.treasury.gov/resource-center/tax-policy/tax-anal...

Less than 5% of small business owners are millionaires.


Yes, in addition I would say if the OA did not understand the dynamics at play enough to have a more specific takeaway than "be more likeable" I predict a very difficult time hiring and managing a team.


If an expat from India, out of his element and native country, with no education or financial backing besides a punishing loan, can run a profitable 7-11, you can run a business too.


> > > Or you can just start your own company and make your own rules.

> can run a profitable 7-11

Which is anything but the kind of business where you "make your own rules." 7-11s are a type of business known as a "franchise". To get an idea what that means, just see the company's FAQ [0]:

> 7‑Eleven provides a fully stocked, turnkey operation [...] obtains and bears the ongoing cost of the land, building and store equipment [...] pays for the water, sewer, gas and electric utilities [...] pays for any building rent and real estate taxes [...] provides financing for all store-operating expenses [...] provides bookkeeping, bill paying and payroll services for store operations [...] provides a support structure and business consultant who meets with the Franchisee weekly to help maximize store performance.

TLDR: It's not a relevant example because it isn't the kind of empowerment (or risk) we're talking about.

[0] http://franchise.7-eleven.com/franchise/faq


>a punishing loan, can run a profitable 7-11

Not really in charge of much if they do that are they?


>> You must earn respect before you trash the system

True, but in addition to that and I guess more important is to get the mandate to do that from the upper management. Make that mandate a part of your job role. Then whether the team likes it or not, truly respects you or not, an official mandate makes it doable.

The other side is while for very practical reasons teams create all kinds of debt to move forward, we also tend to settle into a working mode using the adage of don't fix if not broken, which can be very expensive if you need to scale or pivot, and this just does not apply to start ups. Most big companies that sink I think is because they have created all sorts of invisible debts and there are people who might have fixed it, but their passion not backed by a mandate never lets it get fixed!


Well said! I think another equivalent "coping strategy" is realizing less than dependable designs often arise "organically" like weeds in an unkempt (code) garden, which involves no malice, might just involve being busy from being, as you noted, in production.


Failing to do #1 makes you The Ugly American [1], which has always been my analogy for it.

[1] https://en.wikipedia.org/wiki/The_Ugly_American


> 1. You must earn respect before you trash the system

This is a symptom of an entrenched workforce and quite a red flag.

Juniors have to prove themselves - other should not: that's what interviews, CVs and experience are for.


> This is a symptom of an entrenched workforce and quite a red flag.

No, it's a sign that many domains are full of hidden constraints and pitfalls. For example, it's easy to nit-pick a distributed storage system (such as the author seemed to be working with) as too slow and complex, until you actually learn about the consistency/recovery/etc. corner cases that make a simplistic "just do this" proposals non-viable. You could say that's a failure to document the requirements or design. You could also say that people shouldn't need to document things that are considered baseline knowledge in their domain, and that maybe you do need to show some understanding of the complexity before you seek to do away with it (cf. Chesterton's Fence).


I've seen great CVs document excellent experience for poor performers.

And I've also seen great coders dissolve before my eyes (in the face of personal problems) and turn into very poor performers that routinely caused short and long term technical problems.

I don't think you just need to earn respect when you join an org - I think you need to deserve the respect you earn, and work to maintain it.


Cash Rules Everything Around You. The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it.

I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.


What a toxic environment, it sounds like you did that developer a favor in the long run by saving him from having to work with you.

A developer took the time to review the existing code, and point out things that could be improved upon. That's part of our job. Even if you don't want to make any changes, or he's wrong about some of the feedback, you should be grateful to him/her.

How much revenue your code is earning says nothing about the quality of the code. That you feel the need to mention it says something about your ego.


> How much revenue your code is earning says nothing about the quality of the code.

It does say something. In this case, it might be saying that, for this particular application, the quality of code is simply not that important.


Or perhaps that figure could be doubled with leaner code that's quicker to work with and understand.


It’s possible that this code has bugs that have yet to be detected. It’s a fact that quality is important if it can generate losses. Style may not be particularly important, but reliability is.


No it doesn't. It's a variable that doesn't enter the equation at all.

Maybe the technical debt should be reduced, saving the company money down the road by reduced maintenance costs and reduced issues as development continues.

Maybe the code is feature complete and there's no reason to change what works. It has technical debt, but perhaps the business calculation is that there's not enough benefit to cleaning it up (and in fact messing with working code may introduce issues.)

Either way you look at it, how much revenue it produces doesn't enter into the calculation.

Now you might say the revenue is so low that the code brings little value to the company and so the technical debt doesn't matter. But again that's looking at the wrong thing. Even if it brings in zero revenue, as long as development is ongoing because it brings some other form of value to the company, then the technical debt matters. The right things to look at are the costs involved in cleaning up the technical debt, vs the costs of continuing on while ignoring it. It's all about weighing costs and not about revenue.


Revenue is actually the only calculation - it is a business.


No, it's profit = revenue - costs.

But it doesn't matter to this particular decision which is weighing one cost (technical debt) against another cost (fixing said debt.) There is no revenue in the calculation at all to consider, just costs.


So they need profit, which is negatively impacted by costs.


> How much revenue your code is earning says nothing about the quality of the code.

It says everything it needs to say. Revenue pays developer salaries.


>Cash Rules Everything Around You

No, believe it or not some people prefer dignity.

>The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it.

Whether it had $300,000 or 10M revenue, doesn't change the fact that it might had 300 things wrong.

Not to mention that a single thing done wrong could still result on some large embarrassing outage, customer data exposure or deletion, etc, and result in costs/fines worse then those $300,000.

("Yeah, I've made millions out of this web service, who cares that I store customer credit card details in plain text").

>I have dozens of applications in production

Any specific names, so we can avoid them?


("Yeah, I've made millions out of this web service, who cares that I store customer credit card details in plain text").

The European Union. If you have any of their residents in that database, then you have about 3 weeks to fix that...


Unless they don't audit you.

In which case you can continue not to care.


From my own experience talking with CEOs, I really think that will continue to be the case. If you're asking them to accept a large concrete loss now to prevent a hypothetical even large loss at some point in the future, they won't care.


> No, believe it or not some people prefer dignity.

Nobody ever ran a successful business on dignity.


You'd be surprised.

It might be true that nobody ever made a hugely profitable business on dignity.

But it's absolutely false that that aren't businesses that are successful with dignity.

So, depends on your definition of success.

If it is "supports me and my workers and can even moderately grow and produce good stuff for my customers" then many did.

If it is "I want to eat the world like Uber" perhaps no one die.


s/no one die/no one did/


"Dignity and an empty sack is worth the sack." - Ferengi Rule of Acquisition #109


Yvon Chouinard built his billion dollar business Patagonia with dignity. One of the best things I learned from reading his book, Let My People Go Surfing: The Education of a Reluctant Businessman, was to grow sustainably and only when necessary. It surprised me because it seems to be the exact opposite advice of mainstream startup culture, exponential growth.


You fired for someone finding bugs in your code?

This is beyond ridiculous and you're creating a hostile environment for your developers. It'll come back and bite you in the future.


He was fired for doing an unsolicited code review, which the grandparent did not ask for nor deemed necessary. Plus the wording implies the grandparent felt attacked - as the thread earlier mentioned, you shouldn't barge in and go all Steve Jobs and yell THIS IS WRONG! THIS SHOULD BE FIXED! right off the bat.

I do understand it though, and when you're fresh in a project it's easy to go for the low hanging fruit like that. But, be subtle about it, ask if it's welcome, that kinda thing.


What the hell is an unsolicited code review?

When you start work with a new codebase you spend some time to get acquainted with it. It only makes sense to take notes of bugs or possible improvements when you do it. A pair of fresh eyes will always find improvements to be made.


This so much.

If you expect me to take on a project without looking at the previous code then you're simply a fool.


I really wish companies let you have a look at the codebase before you started. Like, sign an NDA and give you 15 minutes to look at it.

It would've made me reconsider the job I currently have. Upon saying that, I am enjoying the challenge of trying to eliminate as much tech debt as possible.


I see your point, and I agree that it's good to be nice to people.

But being in leadership and spending time around a few hundred coders over the hears has taught me the value of someone who does this.

I hope this wasn't the reason the person was fired, because it's a missed opportunity for management: someone with that kind of drive and commitment to quality is valuable to have - and hard to find. I can count with my hands the number of developers with that kind of drive I've found.

With no further context - meaning: I'm making a lot of assumptions here - I think I'd've helped them schedule time to evaluate these opportunities for improvement (how much do they cost to fix? how much will they cost if not fixed? How can we prevent this from getting in new code? etc.), and when the numbers are right - schedule time for fixing them, too.

If non-agreeableness was their sole defect - it could've been worked on over time. That's what leaders are there for: to help their collaborators grow.


'unsolicited code review'???

dafuq is that? The more eyes on a piece of code, the better.


Grandparent?


Parent = the comment that this comment replies to.

Grandparent = the parent of the parent.


Thank you!Neverheard of it referred to that way before but it totally makes sense!


Often abbreviated as "GP".


Why many of us do this: It's often easier to refer to previous posts relatively rather than to cite usernames. For "OP", others will know to simply look (or think) back up to the top (or thereabouts). For "parent", it's usually the comment above the one that is being replied to. So parent to your post is what I'm referencing, but I'm now replying to you (and have taken no notice of the usernames because it's easier to focus on the content).


One also often sees the same line of argument continued by other posters, so while the conversation is consistent with two (or more) sides being explored, the posters change. I really like this about HN - it really is a group conversation most of the time.


Sounds like he lucked out by you firing him.


"dozens of applications in production"

is that dozens of apps supporting one business, or dozens of businesses?

Plus 2000 lines > $300K - I think you beat Pieter "Think of the Frameworks" Levels - https://twitter.com/levelsio/status/938707166508154880?lang=...


A common illusion that developers tend to have is the "I'm right, why can't they just see it" syndrome. Without knowing the full story, who knows what actually happened there. When you're working on a team, it's completely different from working alone because productivity at scale is totally different from churning out code by yourself

One of the best advices I've heard about starting a new job is that, shut up for 6 months and just do whatever you're told. Don't make any decisions, don't make any improvements to the company process, and don't argue with people. Be relentlessly curious and ask lots of questions and follow the herd. Learn everythig you can about the process - the pitfalls, who are the strongest and weakest teamates, who are the difficult ones, who are the influential ones, how do they resolve issues.

Once you learn the team's in and out, you have more leg to stand on when influencing decisions. That's when you start suggesting improvements, drawing on the solid experience and trust you've built over the past 6 months

From your story, it's clear you wanted to "do it my way" from the get-go and had no patience or respect for other people's way of doing things. It has nothing to do with like-ability or being right and certainly shows lack of professional experience and judgement. I would certainly not want someone like that on my team, no matter how technically gifted they are because an asshole player like that would derail any software team


> shut up for 6 months and just do whatever you're told

I've found it better if I don't shut up, I tend to ask a lot of questions. I still do what I'm told (that's what I'm getting paid for, ultimately), but the chance to ask questions is one that shouldn't be passed up.

The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?"

And, ultimately, every company is kind of fucked up. Each company is fucked up in a slightly different way. Accept this as your starting point, try and figure out why it's fucked up (your first 6 months), and then try and fix it by working with your co-workers (who, despite working at a kind of fucked up company are probably at or above the median for human intelligence).


> The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?"

Absolutely. Ask questions, all the questions. Just be smart about it. There will be time later to discuss these things, and the company will have reasons. If the reasons are ones you can't live with, get out, but you're not in a position to affect real change at this point. But for me when a junior dev is asking questions, it tells me they are actually invested.


Asking questions is an effective strategy - it comes off as wanting to learn rather than wanting to teach.


> Without knowing the full story, who knows what actually happened there Without knowing the full story, who knows what actually happened there.

Chesterton's fence:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence


No kidding. As someone who has a good bit of difficulty with social interaction (no diagnosis, but it overlaps with issues that ASD and ADHD people often report), I've failed a likability check or two in my time. I've had conversations where someone seems to be offended or otherwise put off and I have no idea why. But even having those problems, I don't discount other people's opinions and priorities so much that I'd just go in and refactor an existing system without first being pretty clear on who's responsible for it, what problems I'd be solving and risks I'd be creating for them, and that they're okay with it.


There's a risk to this approach. I tried it twice (with ~3 year gap in between), and twice I lost myself and had to re-train to be my usual self.

Bad habits are contagious, momentum gets lost. Conformity is a strong force.

I've been lucky to have great leadership to learn from and model, and who've taken time to guide me through why things couldn't be fixed at a certain point in time - or plain asked for patience and scheduled time to devote to my concerns.

Given good developers are pretty much in demand, I think we can afford to stay true to ourselves most of the time and just shop around for leadership that suits our style.


Absolutely agree. I will make the one addition that "6 months" as a time period for that "nascent" stage is actually a variable based on how quickly you can connect to the rest of the team. Size of the team is also a factor on this variable. For example, if you're on a team with 3 other people and you're a generally sociable, like-able, persuasive individual, that time period to ramp up and start affecting change on the team might only be a month. If you're a grouch, you might be looking at closer to 6 months for that same time because it's harder for you to win the team's trust. Nobody wants advice from a mean stranger but they will probably listen to their mean friend.

Size of the team is important as well. The example I gave was 3 other people on the team. Building a relationship with 3 people doesn't take a huge amount of time. But how about an engineering organization of 4 teams and 20 people? Well, now that's going to take quite a bit longer. It's also going to be more difficult and complicated as navigating multiple teams, initiatives, interests is obviously an order of magnitude more complexity than one team and 3 people.


"shut up for 6 months and just do whatever you're told. "

I like this one. I see a lot of contractors come in and write code that doesn't fit with the rest of the code base. They don't make any attempt to understand why we are doing things a certain way. I know there is plenty room for improvement but first make an effort to understand the current situation and only then make suggestions for improvement.


Sometimes a contractor, who has been on lots of jobs and seen everything, can tell immediately that things are not going well. They can see a way out. And 6 months is a long time to watch the walls fall in around you.

I'm in such a situation now. A large rambling app that shouldn't be an app, written in a spaghetti style. Ever more features compounded by a boundless bug list, growing daily. All addressed by too small a team, clutching at 'agile' to make some measurable headway. But its a forced march into a gale, and losing ground all the time.

Contractors were supposed to come onboard to help retool and redesign. But got roped into bug lists and creeping features and daily standup meetings that take 45 minutes. Work is evaluated solely by 'momentum' and tickets closed and other futile things.

So we all turn, turn, turn the crank, because crank-turning resembles work and we're getting paid.

Six months are just about up! So what should I do next? Say something now? To whom? These guys are all marching in formation off the cliff, and have no bandwidth to entertain philosophical discussions about the nature of gravity and the sharpness of the rocks at the bottom.


My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and trust. Then make your suggestions.

A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability.

If you are good you can make improvements in the worst code base without having to change everything first.


> This gives you credibility and trust. Then make your suggestions.

Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.


I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.


Yes, working with shitty code is part of the job. You can't refactor if you can't read other people's code, no matter how bad it is. It's still code, and it probably does something in production that's needed.


Sure bad code that works is defensible in a cost analysis.

But buggy code in an elaborate, overheated pile is not the same as 'shitty code'. Its doing all the wrong things and going nowhere.

Another cost analysis includes 'opportunity cost', the good that you could be doing instead of massaging the dinosaur this product has become. By that measure, work done on this 'product' is money down the drain.

I've fixed megabytes of bad code in my day. If it was just a matter of code preferences, then sure I'd agree. But this thing is irresponsibly put together. So much drama to do so little, that 'fixing bugs' in it is really just moving them around.


I agree that there are just plain bad code bases that aren't worth fixing. But my point was that a lot of us (including myself) have a tendency to immediately dismiss what our predecessors did without having made an attempt to understand the situation.


Let's just say, assuming that you are a rock star and everyone else can't code is a poor starting point. I have been on the receiving end of this attitude, and it's not pleasant. These people just come across as arrogant, and they look really bad when they screw up right out of the gate. Some humility goes a long way, EVEN IF YOU ARE 100% RIGHT.


That's exactly it, professional experience opportunity cost and what you spend time getting good at.


So it sounds like: you're a contractor (i.e. you are part of the most disposable group of people in the building), you have a fixed duration of work (presumably with an option to extend... but that's not a unidirectional option), as a group the contractors scope of work has been altered (from strategic to tactical), and your contract is almost up.

If this isn't what you signed up for and have other options, provide the customer of your intent to end the engagement when you have satisfied the term of the contract at 6 months (don't do it early, just give whatever notice is needed so you can end it on time). Don't assume that anyone there cares about your ideas on how to fix things or they would have asked you already.

One big caveat: if you're going through a 3rd party contracting company I've got some bad news for you... you probably never were there for the strategic work but rather to be a warm body to sit there and be billable so just put in your notice and move on. Worst case, you get offered more money to keep putting up with it (make sure it's a real increase... I'd go for at least 15-25%)... and if that appeals to you, enjoy some easy money riding it out for a bit longer.


Honestly, I'd probably get out. Some things just aren't fixable. I'm in a similar situation now and really weighing just finding a better place, but of course there are some complications.


Suggest some overall changes, which if they aren't taken seriously, increase your rate for the next six months?


I've approached the topic of changes, and been shut down each time. They've got so much on their plate, talking about design is the last thing they want to do apparently.

And yeah 'rate' at a large corporation is an intractable thing. My contracting company (I'm a partner) is billing through another contracting company, which is billing thru a billing company, which is contracting the client. The deal was, take this rate or take another job.

Which means, I've been looking constantly for another gig of this length or better. Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.


> Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.

The company agreed to (or set) your rate, they set the assignments, you've done due diligence in informing them of higher level issues, you have nothing to feel guilty about.

Things often have to hit some minima low point for larger changes to be considered. Hopefully they'll still have to resources to stay afloat while the change is enacted... but personally there may be little point waiting around for it unless you see an opening to where you can help at a higher level (and at a higher rate) and they're willing to accept it.


That's ... eerily familiar. Almost as if you were sat in the same team as me.


As a new person, you may see things that are blatantly obvious to you, sort of this stranger effect, and half of the time you will be right.

The other half of the time:

* You are just wrong.

* The issue is already known to everyone but it has been deemed low priority.

* Things may seem wrong but they are that way for a reason.

So, pay attention, make a mental note of issues, but don't bring anything up in the first few weeks, as you may look at best silly, at worst, like a whiner.


The flip side, is that this is how deviance is normalized.

https://danluu.com/wat/


> Don't make any decisions, don't make any improvements to the company process, and don't argue with people

I disagree. Do these things, just do them in a subtle manner.

Nobody likes someone who comes to a new job and can't stop saying "at my old job we did XYZ in such a way". It's annoying and condescending.

Nothing wrong with hinting at improvements though. Trivial example: rather than "we should all be using rubocop", you could mention in passing that rubocop really helps you write clean code.


Expanding on something I mentioned in a different comment: I wish more managers were up front with the pain points.

If I can explain our refactoring/internal improvements road map, and give brief backstory about why the current state is the current state, and save someone weeks or months of "ugh is this code really the best thing we could be doing here?!" context-less fumbling, that's a great tradeoff.

I suppose it could backfire, if [new hire] immediately disagrees with my reasoning and comes to the conclusion that I'm just an idiot who's bad at that stuff, but is that really going to be worse to hash out some on day 3 instead of day 40? If [new hire] turns out to be an asshole who isn't open to other people's opinions, let me find that out ASAP.


6 months is VERY long though, in software development; if you have a six month trial period (which is also pretty long, although OTOH the more common 1 month here is pretty short), you also kinda have to prove yourself, to show to both your peers and the boss you're an asset. So yes, do start focusing on the actual business and such first, get a feel for the culture. If there's other people that e.g. submit cleanups / refactorings, then point out an issue and ask if you can take a bit of time to clean that up - for example, and assuming you don't have anything more important to work on at that time, etc.


RubyConf 2017: Keynote - You're Insufficiently Persuasive by Sandi Metz - https://www.youtube.com/watch?v=VzWLGMtXflg


>While I know I made many mistakes, I believe I was not the only one who did... but I was the one on probation... so... so long and thanks for all the fish.

Author seems somewhat arrogant, one of the worst personality traits in my opinion. Hard to be liked if you're arrogant.


Lol go king kong on their shit


Random thoughts: 1. Say if you are hired as a gardener. But let's say your skills are much stronger in Botany. You might be fixated on why certain species are not planted and why the folks who planted it are stupid to have the plants that they decided upon, and how you might have a better idea on which plants grow best in which weather. Remember, you are still a gardener. Maybe if you work your way to earn the trust and respect of the people, one day, you might have the support to express your other skills in a better way and actually make a difference.

2. If it's one person that you have a problem with, there is a possibility that they are the problem. With two,the probability decreases a bit. With three or more people, the probability goes the other way round - you are probably the problem.

3. Watch 'Jiro dreams of sushi'. The cook took several years before he was allowed to bake a simple cake. It is not just a matter of knowledge, skill or even passion. It's being accustomed to the environment, being useful in some area to the business and making meaningful contribution before other nice things materialize. You still need a lot of skills, passion, talent and work ethic; but those are not the only things.

Kudos to the author in spotting a blindspot. However the tone of the articld still left me wondering if they actually still felt that they were better than the rest or if they realized their limitations.


It's a little more complicated in this case than for a typical gardener. The developer works for their manager, their team, but also ultimately for the firm. The developer may well be pursuing explicit goals of the firm, while annoying their peers or manager. And the developer may be right!

Teams reach a kind of stable state. New hires may well represent a desire of the firm to change that stable state. The team may not be on board. Sandbagging is not so uncommon.

In this particular story, the review situation is what particularly raised flags for me. Obviously the author did not situate himself well, but I'm not sure he'd have been happy if he had been more adaptable, and that may be on the team and not him.


Love these thoughts. I think the code craftsmanship movement really speaks to your 3rd point, but the whole industry is incentivized against it. Especially in SV, if you don't get into a company, make a major contribution, and get out in 3 years then hiring managers start to see it as a red flag. I really love the cross-pollination of ideas this brings, but it also wreaks havoc on stability and institutional knowledge.


#2 is just not true. If you're in a room full of klansmen who are all going on about how whites are the superior race, and you disagree. Are you the problem? NO!

The same is true of anything else. Sometimes the whole team is totally wrong, and their way of doing things is detrimental to the overall goals of the company.


> If you're in a room full of klansmen who are all going on about how whites are the superior race, and you disagree. Are you the problem? NO!

Well, yes actually, you are. By what mechanism does a group of clansmen become one notch less destructive? Certainly not by having newcomers tell them non-whites are equal.

They become less harmful by A) feeling like they have the institutional support to take care of their own, so they have less need to lash out, B) having safe, passive exposure to The Other, and C) having people they trust question their worst ideas.

If you’re not making some similar constructive move, then yes: you’re part of the problem.

Notice that we’re not saying you’re wrong. Of course speaking out against white supremacy is right, that’s a separate question from whether it’s problem or solution.

It’s easy to be correct while contributing nothing to solving a problem.


mindfulplay wrote that it's "probable", not that there is no way that everyone else but you is the problem.


Some of the other comments here seem to exemplify the just-world fallacy. If all software teams were so functional, sites like coding horror wouldn't exist.

The dirty secret of software development is that the vast majority of it is done very suboptimally. Both in terms of time taken, and the approach taken to solve the problem. A technically skilled engineer is able to spot these shortcomings and improve on them. A politically skilled engineer is able to get buy-in from the rest of the team, in order to make things better. A well functioning organisation is one where the talents of the technically-but-not-politically skilled engineers, are harnessed to their fullest extent. Not as a favor done to that engineer, but because it helps the organisation itself.

From reading the story, it's clear that this team is even less technically competent than others. It's also clear that the author is very technically skilled, but not politically skilled. Unfortunately for him, the organisation isn't highly functional either, likely stemming from its very political team lead.

In such situations, you essentially have one of two choices. Quit and look for a better team. Or stay, accept that you're working with a bunch of dunces, and do the best you can while getting along and collecting your paycheck.

I can relate because I found myself in a similar situation at a previous job, with almost the exact same quarrels and frustrations. Luckily for me, my team lead was much less political and more open to outside suggestions. Because of this, I was able to ram-through what I thought was the right solution, even though I was constantly butting heads with others. Looking back, I realise how lucky I was to have an open-minded non-political team lead, and how rare that actually is.


God same for me. I read this post and thought I had written it myself. I'm a very pleasant person to work with, I will never belittle others or be harsh about anyone as a person. I will absolutely say when code/architecture/system is poorly designed, and I will say why. This should be a good thing in our industry, but unfortunately it's not.

If a civil engineer came to a team building a bridge and noticed everyone was building something dangerous, he MUST say something or people will die. Imagine a world where the rest of the team poo poo's him for "not getting along."


Hmmm yeah it really does sound like this guy and the company were a bad fit.

There is an old joke that after an interview you should ask 3 questions:

1) can she do the job 2) can you work with her 3) is she an axe murderer

OP can certainly satisfy one of these criteria but even if they’re okay on (3) not meeting (2) is enough for exclusion.

When you find yourself in a toxic (from your perspective) situation you really only have 2 options. If you decide to stay you have to make the best of the situation and get on with people.

It sounds like OP responded to this situation in a way that probably wasn’t in line with this thinking. It’s all well and good being “right” but such accomplishments are marred quite a bit of you’ve annoyed everybody around you in the process.

I’m speaking as somebody who has been through this cycle a few times and finally settled on “getting on with people” vs “being right” after I got the feeling I'd changed job a few too many times.

The transition in this way of thinking was actually quite painful and I made many slip-ups whereupon people would presume I had slipped back to my old ways and couldn’t change - the scorn still rings in my ears. But eventually I did and now I’m one of those effusive hackers that gets on with people, and just drops into tricky situations as they arise. A highly prized resource it would seem going by how my salary responded.

Anyway, as poor old Janis would say “if you can’t be with the one you love, love the one you’re with”. You’ll be happier and your stress levels, blood pressure, social life and even maybe your payslip will reward you for it.


One question some eager beavers might be asking is how do I deal with things when I see something that is obviously wrong. It depends, but if it's something that's well established and everybody has learned to live with I note it privately. Then I know where the bodies are buried and if it does become an issue I can point it out pretty quickly.

If it's something that's more immediate usually nature will take its course, but if it doesn't usually a quiet word in a tester's ear can elicit the necessary dialogue.

With regards to other people being "lazy" and "not fulfilling their role" I prefer to take a position of unconditional positive regard and presume that everybody is busy ... my cardinal rule when making big changes is "cause as little extra work for other people as possible".

Keeping people busy is management's responsibility, and if I'm totally going to pull the rug from under something I'll get them on board. If they tell me to leave it alone I leave it alone but I've told them what the issue is and its their problem now, to weigh up and act upon as they see fit.


I get the sense that the author of this post is fairly young. It's pretty interesting, if you look at the graph from the Stack Overflow survey of competitiveness vs kinship with your peers, it drops pretty rapidly with experience: https://insights.stackoverflow.com/survey/2018/#connection-a...


While studying social psychology of what makes a kid popular vs unpopular (on Coursera), one significant factor was that an unpopular kid came into the group and tried to play a new game. Whereas a popular kid just went along with whatever the group was doing and then after a while suggested they play a different game.

Clearly there are some parallels with this story here...to be "popular", he should have gone along with whatever they were doing and slowly try to change things. Not saying that's right or wrong, but hey, that's apparently how you get popular.


This is basic human interaction 101. If you approach a gourd of people talking and try to change the conversation immediately, it won't go well. You need to listen and participate in what's already happening first.


It seems to me, being "popular" is more an attained status rather than any kind of quality. What I mean is, the kids who went along with the group gave the group an opportunity to evaluate the newcomer - and gave the newcomer a chance to build some level of likeability, trust, respect.

One may be all of those things, but without giving the group an opportunity to discover that for themselves, they aren't going to listen to your suggestions. Or one may start by going along with the group, but be abrasive and obnoxious, and no matter how much time they spent with the group, they won't be popular.


It doesn't mean anything if you are "right" but nobody will listen to you. To effect any change you have to not only be "right" but also be able to convince others around you of what you are trying to do.


This used to be one of the great ways that tech was different. You didn't have to convince people through social means. Often there were purely technical merits that could be objectively proven. And people cared about the code more than "being right." Obviously that's not a blanket statement, but it did used to feel representative of the overall culture.

Over the years we've backed away from considering the value of things on their technical merits. I'm not saying we shouldn't be thinking of business value, but you have to admit that's far more subjective. I'm not always sure it's a good thing. I'm convinced that maximizing business value and ignoring technical value is one of the main reasons so much modern software is crap.


> While studying social psychology of what makes a kid popular vs unpopular (on Coursera), one significant factor was that an unpopular kid came into the group and tried to play a new game. Whereas a popular kid just went along with whatever the group was doing and then after a while suggested they play a different game.

I remember reading about such a case in Emotional Intelligence by Daniel Goleman. So, curious what is this course?


On Coursera it is called "Social Psychology" offered by Wesleyan University. I don't see any upcoming sessions, but there may be an archive somewhere.


an unpopular kid came into the group and tried to play a new game

Interesting parallels to newcomers to tech/geek culture in general too.


I'm currently in a consulting gig coming up on my one-year anniversary. I'm helping maintain an internal development tool that was written by the company's CTO over the course of the last 30 years. It's some of the most godawful code I have ever seen: functions that are many hundreds of lines long, lines that are many hundreds of characters wide, weird state dependencies all over the place. It is literally impossible to work on this code base on a laptop. My client has two enormous 5k monitors on his desk. (I have to muddle through with just one 4k monitor, and that's barely adequate.)

And yet... somehow, it all works, and at the end of the day, they ship their product on time and make a boatload of money. So my visceral reaction to this code is a very strange mixture of horror and respect.

My approach to trying to get this mess fixed is something along the lines of, "You're the boss, and it's your call, but if I were one of your investors I would be very concerned about the long-term maintainability of this system if, God forbid, something were to happen to you."

Does this approach work? Hard to say. No substantive changes have been made. But I haven't gotten fired either.


That is how all code that makes money looks.


You are thinking like a junior programmer and instead you should be thinking as an investor. The investor gives little to no damns about your opinion of the underlying code base.

Investors do not make fortunes based off the opinions of junior programmers nor on their understanding of the nuances of codebases.

Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.

My advice to you is the age old adage, put yourself in anothers shoes, go and buy some stocks, etfs, mutual funds what have you and experience the other side of business, let your eyes really be opened before casting judgement on processes you have little understanding of.


> Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.

It seems as if you're going out on a limb here and inferring an awful lot about someone from a single comment, and your inferences both appear to be incorrect to an amusing degree...


> Investors do not make fortunes based off the opinions of junior programmers nor on their understanding of the nuances of codebases.

Investors can lose money on bad code bases. Technical due diligence is a real thing. And getting a third-party opinion on "if your CTO dies, does your business also die?" is EXACTLY the sort of thing that comes up in those conversations. E.g., https://dave.moskovitz.co.nz/2016/08/29/technical-due-dilige...

If a technical audit comes back with "the CTO is the only person who can maintain this code base", and if the code base itself is a major asset the buyer is interested in, that can kill or substantially modify the terms of a deal.

> Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.

(e: removed silly speculation)

> ...go and buy some stocks, etfs, mutual funds

This provides zero insight into what technical due diligence looks like or how that plays into the overall decision to purchase or invest in a company?


You both (@patreus, @throwawayjava) might want to take a quick look at my profile before you start speculating about my financial situation.


Not only is your comment misguided, it's also very rudely formulated.

Many organizations fear the departure of institutional knowledge that goes hand in hand with retiring baby-boomers. Many investors/corporations also take out life insurance policies for key employees because they are so instrumental to the work process. A labyrinthine code-base without well-defined knowledge transfer processes spell capital disaster.


Investors do not make fortunes based off the opinions of junior programmers

Tell that to the investors in Knight Capital.


Win the battle lose the war.

The author doesn't pick his battles intelligently. His victories are at the expense of his team: instead of making his team members look good he makes them look bad.


This is an excellent point. A lot of times, our personal pathway to success is by clearing the path for someone else to succeed.


There is a bigger war, though. Other teams, other companies.

You want to keep what works, change what doesn't work. If your team doesn't do it, another team elsewhere will.

Then, people never stay in the same job forever. If you use your power/team to stay mediocre, you are just acting against your own self interest.


When things aren't working their best, the #1 thing that has to change is the team, not the technology. Change the team and the technology change will happen automatically. Try to change the technology while alienating the team, and the tech changes won't get done or won't stick.

One way to change a team is firing/hiring, and I bet many readers' minds probably went there first. But firing and hiring are very expensive, especially in a time-constrained business, because time has a cost. And only a few people have the power to do that.

Another way to change a team is to alter or improve the people on the team. The value of influence--the ability to change the minds of people around you--is underrated by a lot of people, especially engineers who spend most of their time in a headspace where things are quantifiable, black and white.

A new person coming into a team that builds technology, who wants to change the technology, needs to focus first on changing the team via influence. This is a skill that anyone can learn, but it has to first be a skill they recognize and value.

The lowest person on the totem pole can't fire anyone, but they can certainly influence people. In fact, the ability to positively influence the people around you is a key skill for anyone who wants to grow into a leader in their profession.


If you think in terms of pure performance - social interactions, adoption just take too much brainpower, energy and time. If the management is smart, hiring the people who lack (and do not spend the time to that) those social interaction skills can improve the team performance to new heights. What is tricky in that case - the synchronization of the tasks and progress in the team, but this can be done externally by the manager and software.


It's not about technology. It's about consensus building processes, which are necessary to collaboratively work around an idea.

It is fine to spend time discussing and building consensus. And it is fine if your idea doesn't prevail. But the most important thing is how an idea prevails in a conversation.

If an idea prevails for reasons other than it being the most reasonable idea, like someone pulling rank, or having a higher speech rate, or louder voice, or just being more aesthetically pleasing, you've got a pretty flawed process and this frustrates objective people.

When a person consistently requires a lot of hours of "influencing", usually because their motivations are not aligned with the best interest of the company, you start looking for alternatives. e.g: having someone else to do it, deprioritizing, doing the job yourself, escalating.

When you have a team full of those people, best thing you can do is to make a better use of your time and work on another team or for another company.


Perhaps this explains why I often pass technical screening with no problems but tend to fail 'cultural' fit interviews. It seems that to meet jcadam is to hate jcadam.

I probably don't come off as a very nice person (my wife tells me I have a 'death glare' as my neutral face), until you get to know me. I once had a technical lead admit about a year after I had started a job that she had recommended against hiring me and was overruled by her boss. "You seemed like a jerk at the time, but now I realize you're just an introvert."

So, these days I try to paste on a fake smile when I interview, but to no avail. I suppose it might make me look a bit scary -> vacillating between "death glare" and "creepy smile."

Funny, I got (and turned down) a job offer earlier this week that was based solely on a couple of phone interviews. I turned it down because it was a large corporation and seemed very much like a butts-in-seats sort of place (hence, why would they care about culture fit and actually want to meet me in person?)


Here's a trick for introverts. During those culture fit interviews, as soon as possible, try to have the interviewer let you speak about something you're passionate about.

Few people can speak about things they love with a deadpan face or a frown on their faces. And a smile makes everyone look nicer and friendlier ;)

Especially an authentic smile!

(Note: Don't go on a half-hour story, though, a few minutes should be enough to lighten the mood.)


Good comment about not going on for half an hour. I have failed interviews by going from introvert mode to super excited mode and going on for way too long.

I see that in a lot of engineers. We are just not good at reading social situations.


Think of it like engineering a lightweight anecdote. If efficiency with words is the key, then you know what to do.

Now that I'm a bit older than a young eager 20 or 30's something, I'm better at capping my stories before they get boring or repetitive. Leave them wanting more, or at least give them the talking hat back, they probably want it.


Ha ha ha, you and me buddy, you and me. Smiling helps, but in the end of the day, you are who you are.

There are places I would fit well, and there are places even with my considerable talents I just don't. And you need to accept this.


I thought of just going back to my previous job (the guys made it clear I was welcome to go back) but I was afraid it would make my Resume look like I am too much of a job-hopper.

If you even put it on your resume at all, it’s probably one of the easier ones to explain and helped by the fact that your old company re-hired you. “Would you hire this person again if given the chance” is a common reference check question.


Obviously, the amount of apathy and defensiveness displayed by the other employees is a huge red flag that I'm surprised didn't come up in the interview process at all.

However: Saying things like "I don't believe you," especially in a public setting, is a great way to come off as a jerk. Once you've decided to call someone a liar, the chance of them getting defensive (and thus poisoning your relationship) increases significantly. You've cornered someone instead of giving them an escape route.

Seems like it was a horrible fit on both sides: The author needs a significantly more accountable company, and the company needs someone with a much more delicate touch.


I am surprised that most of the comments here are actually advocating for navigating Dilbert-style office politics as an effective way of "getting along."

There is clearly too much conformism and flawed communication flow in this organization, which is a failure of leadership, and not of somebody who is "actually doing what [he] was paid to do."

The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."

If there is too much conformism, necessary conflict will be avoided and could not be utilized in a healthy way, leading to too much consensus resulting in "one-year old pull requests without review."

In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.

If a competent but "less socially aware" guy moves "too fast," why the team prefers to effectively mob this guy out of the organization, instead of just telling him to slow down?

No such context for constructive feedback, maybe?

This organization is just shooting itself from the foot.

Organizations that need to move fast cannot afford such conformism and dysfunctional communication.


This is just humans being humans. Some people have more capacity for openness and receiving criticism than others. Wisdom comes from taking time and understanding why organizations fail as they often do, and not trying to just fight your way through all the time. It won't work, and people will not suddenly stop being as they are to fulfill your desire for a place where people will immediately drop what they're doing to listen to what the new person has to say. That's not to say that they shouldn't, and smarter orgs will retain flexibility and welcome new ideas. But if you just expect that or feel entitled to it, you're gonna have a bad time.


It's not Dilbert-style because there's no conclusive evidence of incompetence. When you are new, you should be giving people the benefit of the doubt, and tread lightly. Raise these concerns privately and gauge the situation. After a few months it will become apparent if the place is truly dysfunctional, in which case you would need to have left on your own.


The author states he stuck it out for 6 months.


> I am surprised that most of the comments here are actually advocating for navigating Dilbert-style office politics as an effective way of "getting along."

That's unfair. Most people who are advocating for deference when first joining a team.

And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". Therefore, sitting back and learning the social and technical history that led to the current system is actually the correct place to be in the exploration-exploitation axis during the probationary period.

Both for social reasons, as well as for technical reasons.

That's very different from "put up with office politics". The point is not that you should be likable during the probationary period. The point is that people who go way the hell too far to the "exploitation" side of the axis so quickly are demonstrating poor engineering judgment.

Characterizing that poor judgment as "well I guess I'm just not PC enough" is just icing on the cake.

> The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."

According to this account.

I submit that it's not even obvious that the engineer in this story was even making the correct engineering decision. Engineers are not scientists:

> In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.

I think the core problem in this story was wasting a bunch of the company's time arguing over a heuristic that's "good enough" in practice. Both solutions would have been "good enough"; the engineer put his ego above producing value for the company.

> Organizations that need to move fast cannot afford such conformism and dysfunctional communication.

Organizations that need to move fast cannot afford engineers spending time to prove they were correct when going with the established heuristic would've produced a good enough result with far less engineering time involved.

If the story included a thorough cost/benefit analysis showing that the change saved the company $N0,000 with N > (cost of engineering time) then you might have a more cogent argument.


> And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns".

They're mostly not unkown unknowns. They're mostly arcane knowledge of some sort or the other.

And what prevents good communication of this knowledge besides either lack of competence or politics?

Someone didn't know or didn't care to do better and nobody held them accountantable for it.

In particular, the strange horrible code might be there for a great reason. But there is not a good reason for nobody to take five minutes to write a comment about why. And there is no reason to not ask for that comment when the change is reviewed.


You can be:

A: Correct

B: Liked by the team

C: Both

D: Neither correct nor liked

Managers are often okay with incorrect employees because they can be trained easily. (Whether or not management actually trains them, that's another story - but managers like to believe that they could.)

Managers are less okay with employees that everyone actively dislikes because it's way harder to train someone on how to get along with people.


Not just managers, but team-mates as well. People generally would rather be complacent than challenged (I'm no different, of course). And when someone is really wrong about something, it gets really old when he is told so over and over.

It's kind of like in a marriage. The man keeps on doing something wrong (forgetting to pay the electricity bill, perhaps) and his wife keeps on pointing it out — and, rather than pay the bill on time, he instead gets angry that she's nagging!

Persuading people gently, leading them slowly but surely to realising for themselves that they've been terribly wrong, is extremely difficult and requires a high degree of social skills. Sometimes, it's simply not possible: sometimes a team-mate (or worse, team lead) has so much invested in an incorrect decision that he will never change his mind; the one's only choices are to live with the malfunction or leave the team.


Sometimes I'm wrong. It's great to have a team that can point out why I was wrong and discuss a fix. But I know that I'm not always wrong, so when a developer is constantly telling me that I am wrong about everything, it's really annoying. Those types of people are only doing that because they have to be the smartest person in the room. Usually, however, they're not. They're just the person who has to be. Everyone else understands that different does not equal wrong.


100% agree, through the years I've learned that, as you said, it might be impossible to change and what has helped me is to stand in the shoes of the other person knowing how much they've invested.

Related: https://en.wikipedia.org/wiki/Sunk_cost


"Liked" isn't the right term IMO.

I've worked with plenty of people whom I don't particularly like at a personal level, and would not have a beer with given a choice, yet were able to connect with at a professional level.

Honestly, this blog post had a "nails on chalkboard" sound, although it was written by the protagonist from his POV. My guess is that his co-workers would have said that he was a bit of an asshole, and made it clear that he was the "smartest guy" in the room. You can only pull off that bullshit if you are part of the tribe; when you're an outsider, that behavior lights up the organizations' immune response.


"You can only pull off that bullshit if you are part of the tribe; when you're an outsider, that behavior lights up the organizations' immune response."

This, this, one thousand times this!

When I first started with my current job, I had lots of free time, a technical background, and a desire to carve a place for myself. So in the first week I went through the whole website and invoiced where I felt there were some easily fixable UI/UX problems that could make things feel better and possibly get us more clients. Sent that list up the chain of command. Nobody cared.

Fast forward a year: I've learned the culture, how to work with the people involved, and I'm being shifted to a more hands on role with the product decision making. I've learned how to work in the system, so now I'm able to expand my sphere of influence.


Culturally we also percieve people's personalities as fixed and unchanging.

Where as many more of us percieve skills / knowledge as trainable.


> In my first week, I was assigned ... I took the lead in implementing the solution

You took the lead on your first week???

Based on your explanation, your co-workers were morons, but you made one of the most outrageous socially-wrecking mistakes that one may do: you showed an unwanted truth to people you were not even acquainted yet. After that, the cleavage is too deep to even try and feel it. I think letting you go was the right decision, the environment was already toxic and it would have taken years before it returning liveable, if ever!

When you join a new group of people, first of all try and adapt yourself to your new environment, and only later try and adapt the environment to you. Otherwise, conflict is inescapable.


>based on your explanation

This is an important point. This guy may in fact be annoying to work with (I don't want to pass judgement, but I started to suspect that while reading his post).


This guy is definitely annoying to work with. The question is whether he's also the extremely knowledgeable and competent person he paints himself as and whether his coworkers were the bumbling and ineffective people he paints them as.


One very painful lesson I've learned in two and a half decades as a programmer - when people hire you to fix their problems, they only very rarely actually want their problems fixed. In many cases, they'd rather see the entire organization go out of business than see you fix their problems.


Wow, thank you for making me feel like I'm not alone...

I can't even count how many times I ask myself "but they hired me on the premise that I'm an expert in this, so why are they not allowing me to work and make changes to improve things for them?"


This. So true, it almost makes me want to cry. Why is our industry such a mess?


Human nature. While it may be worse in our industry, these issues can be seen in almost any organization, it's just a matter of the degree.

For an example from a totally different direction, consider something like "Kitchen Nightmares". People with a failing restaurant, who know it's failing and have gone out and solicited the help of someone who's considered good at both cooking and turning around restaurants.

And at least 50% of those people still will resist many of the changes they're asked to make even though they acknowledge that they're failing. They don't really want to change, they want him to make them successful without changing.

---------------

That said, I'd suggest these issues are much more common in industries where measuring results is hard and where results aren't an automatic result of work put in.

"This thing will improve production on the assembly line". Great, try it on a line and see if output improves. Hard to argue with the results if it does, even if it's just 5%.

"This thing will make better code/software". We can argue about this for hours, we can trial it, and unless it's a massive leap forward it's unlikely you'll get such a clear-cut result that a person biased against it/against change will be swayed.


This business requires many to be confronted with complexity at scale. I think these problems are universal but few encounter them due to the distribution of employees in organizational hierarchies.


Wow, that was hard to read. The writer really doesn't seem to understand any of the fairly huge missteps he made that led to his dismissal.

Being technically competent isn't the only factor in job retention. I feel like this is an especially difficult fact to accept for some of our tribe.


Assume good intent.

It's kind of a motto where I work. Others are surely familiar with it too. I'd also add that baseline levels of sanity, competence, etc. are all part of intent for the purposes of this admonition. It's a good rule, and the OP demonstrates exactly how things can go sideways when it's not followed.

Maybe others didn't recognize the author's good intent, but he clearly didn't recognize theirs either. As far as I can tell, he doesn't think they ever did a single thing right until he came along, which is a huge red flag. I doubt he felt that way when he accepted the job (why would anyone?) so it reeks of post-hoc rationalization. Remember, we're only hearing one side of the story. Chances are, even if he was right on the major points, he has elided how his first ten "you just need to" proposals had to be amended in a collaborative process for which he denies anyone else any credit. Counting the hits, ignoring the misses. If he had assumed instead that other people weren't idiots, that they had reasons for what they'd done and would be amenable to reason, there might have been a better outcome.

P.S. Yes, I know sometimes people really do lack good intent. Some people really are mean, stupid, crazy, etc. Believe me, I've worked with a few and I've called them out on it ... but only once there was incontrovertible evidence of those things. It doesn't change the fact that it's better to start by assuming good intent.


There is a difference, I think, between healthy and unhealthy conflict. This team was clearly averse to both. It was likely an awful team.

My advice to anyone in a similar situation: work on the classes of behavior that are actually problematic, namely blaming, defensiveness, contempt, and stonewalling. Then you can have a healthy argument about ideas.

If a team has problems listening to actual, clear evidence that what you did was correct, they are perhaps at fault here. Of course, if you show contempt, then the right thing for a healthy team to do would be to:

1) Address the contempt head-on, and then 2) Examine the data dispassionately.

It seems this team failed at both.

Probably a good thing to get fired from such a place, though it hurts to not be given an opportunity to move on on your own terms! This particular org appeared to be a pretty bad place to work anyway.


While I agree with you, reading this showed and ego coming from the writer, but in his place probably should have handled it better in a new environment. What I was reading felt more skewed towards "I was right and got fired, but made no attempt to communicate sans telling people they were wrong".


> There is a difference, I think, between healthy and unhealthy conflict. This team was clearly averse to both. It was likely an awful team.

I didn't draw that conclusion at all. It didn't sound like he was advocating healthy discussion. He came off to me as being brand new to a team and insisting on his way, while not being open to any explanations of why that either wasn't a priority or wasn't viable at the moment.

Walking into a team as a new member and immediately insisting on sweeping changes is never a good idea.


The practices the author describes are actually horrible, and objectively bad practices though. Truly, obviously, inescapably bad practices.

Do you just go along with it? What do you do? I personally try and avoid places like that like the plague because it will mean my technical skills will vanish with the wind the more time I spend working in such a code base.


Every single one of the author's complaints was an opportunity that the author could have ethically leveraged to advance and gain job security, all the way to lead tech (assuming that's what the author wanted).

Is there an industry where people like me get paid to keep people like the author from self-destructing in a near-perfect job environment?


Team psychologist? It's a role that managers end up assuming, often for the worst. Unless you're the rock metal band Metallica, who actually use a team therapist, problems aren't usually sorted out other than by turning over staff, which Metallica can't do without destroying the cash cow.

It's good, but rare, to be irreplaceable.


No, I'm talking about consulting for the employee as a kind of ethical Machiavellian. Otherwise the interests don't align.

It may just be the examples this author gave that made me think of this. An initial temporary team where everyone is clearly less skilled than you are? Dear lord, feed them the answers so that they get credit for fixing the security issue. Everyone will then sing the praises of working with such a team player.

Work closely and non-combatively with the tech-lead to get a full picture of their knowledge and level of defensiveness. Then stay out of the tech-lead's way while you slowly begin building up a robust testing system. Make sure each pull request is short and easy to read. Space them out so you don't make a pile of work for your colleagues.

Pretty soon you'll have a bunch of allies, probably including the tech-lead. Or if the tech-lead is still defensive, you'll have a big, fortified wall of unit tests between the two of you. They'll be forced to argue with failed tests instead of with you directly, which is one of the few (and perhaps one of the only) benefits of technological progress.


Employee-level strategy consulting?


Likeability is not in the mix here. Essentially you came in, looked things over for a few days, and then told everybody "You guys are all shit, and so is your shit code." Your actions provide meaning, and especially so when you are a new incoming team member.


This is very true, note that his very first action in the company was to conflict his coworkers' opinion as to how long a fix can take. The author went to that company, after barely checking the code and the team, decided he's the superhero this company has been waiting for years.


Joining a new team is an exercise in humility.

The better you are (or think you are) the more difficult this is. When I start at a new job I never criticize the code because you don't yet know who wrote it. If teammates grumble about the code base I pick parts to praise. This is counter-intuitive because foreign code and practices are almost never appealing. It is far more important to judge the team culture and fit in than demonstrate your technical ability immediately.

Unfortunately the author does not seem to have learned his lesson as most of the article is about what he did 'right'.

When I interview candidates I attempt to engage them in technical argument where I purposely make some questionable statements. How do they attempt to correct you? Do they leave the door open for their opinion to be incorrect. You can learn a lot about what someone will be like to work with just using this simple technique.


> When I interview candidates I attempt to engage them in technical argument where I purposely make some questionable statements. How do they attempt to correct you? Do they leave the door open for their opinion to be incorrect. You can learn a lot about what someone will be like to work with just using this simple technique.

This is a very good idea! Thank you very much.


Software development can get political in ways that individual contributors don't foresee or even cognitively understand. There is often no established metrics for how fast a department is supposed to work. Managers engaged in department building need to manage expectations for how much work is going to get released.

Working too fast in these situations can and will cause cohesion problems. In this situation, if you have a fix for something that will save weeks of work, don't take a sniff test of the general atmosphere, and just charge forward guns blazing, you will make yourself an organizational pariah.

The easiest way to tell if you're in this situation is to get in a closed door meeting with your middle manager and explain the difference between what people believe about the situation and the actual situation. Maybe even do the work first so you have some solid proof that you're right.

Your manager will know the political atmosphere and how to navigate it better than you will. In most cases, he'll give you political cover to implement your fix and because it's coming from on high, you won't get resented for it.

Of course, if this starts happening a lot, then you need to have more discussions with that manager about a promotion.


The title seems to imply that there’s something wrong with sympathy being a factor. I don’t think there is. Working with people you enjoy being around is probably the single largest factor for my productivity, and ignoring it would be a catastrophe, long-term.

There is, however, a certain obligation to try to get along, to help new hires to become part of the group, to overcome all the biases we all have etc.

I’ve also not seen too great a tendency to streamline personalities for the sake of “getting along”. Indeed the most fun and productive groups were rather diverse sets of characters, including the stereotypical “asshole genius”. Somehow, they managed to keep insulting peoples’ work yet showing enough self-awareness to make their subjects not feel personally hurt.


PRs are not getting reviewed. Solution? More PRs. That doesn't sound like the right solution. Seems to me the author didn't bother to get to know his team at all.


From the article:

> This accusation lead to another confrontation where I became aggressive (the guy attacked me personally), which probably was the last drop for them.

This leaves a lot of room for interpretation. If he got physically agressive he would be fired on the spot pretty much anywhere.


This post resonates deeply with me, explaining exactly how my experience at some points as been working with people. I am still in the early stages of my professional career, so I am nowhere near a stage where I think I am even close to know pretty much anything to the standards that I have mentally set for my self.

But I have found the share amount of employees, which just bloat confidence in anything they say, even if it is the wrongest thing in the entire Universe.

Always prefer to lower the bar around the quality of code, translating into more problems with future requirements, readability and so on. The reason? Self-preference to bad habits, but also the "no time" excuse, which in some cases might be the appropriate choice, but in others simply translates onto an obvious lack of ambition, but also a mind-blowing lack of respect for the programming art.

And I say this knowing that I am nowhere near the level which I want to be and very far away to actually produce code that I can consider to have met the standards of anyone with level of expertise in the same subject.


You are so lucky! You have a huge chance to note the experiences of the author, and _change course_ now before you end up unemployable years down the road! (like the author, who is going to be one of those aging coders who can't seem to get a job)

The author clearly seems to know computers, but in general from reading his post, he is a bad engineer. He collaborates poorly, he offers solutions without context, and does dangerous things without even realizing it. (eg: the use of BATCH without consideration for the negatives of such)

One thing to realize is you are holding an absolutist view of programming as an immutable art form. Programming computers is an engineering discipline. It exists to serve an external purpose - help people, make money, solve problems in the real world. Like every engineering discipline, it involves a trade off. Marking off your coworkers as "obvious lack of ambition" and "lack of respect" in their efforts based on your own judgement of their coding skill is intensely disrespectful. That's the kind of attitude that is inherently pre-judgemental and is what can get you fired, not hired or just edged out.

Having worked with truly intelligent individuals, one thing I have noticed is their endless humility and lack of ego. They are kind, think well of others and endlessly question their own intelligence. The author falls short on every metric.


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

Search: