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.

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.

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.

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.

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.

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=...