Hacker News Reader

Comment by guappa | Hacker News Reader

Once a coworker spent 4 weeks arguing with me that his code was fine because "the test was green" before I touched it.

The test contained a "return true" before the actual test.

After writing countless emails to convince him to fix his code, and wondering why they wouldn't just fire him and save everyone else some time, the CTO announced that the guy was now promoted to team lead. :)

His code is not elegant, it barely works, requires constant full rewrites, is an endless source of segmentation faults, deadlocks, sleep() in the main thread and whatnot.

The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.

Estimates are important.

I've overheard a team lead claiming they are completely impossible.

How long does it take you to go to the store? Yes you might die in the process and take ∞ time, but one normally considers common inconveniences in this. A senior who can't estimate isn't a senior.

Of course at work I've heard a team lead say "I did my part, I have no idea when they will implement it" (not the same team lead I mentioned before).

> It will be almost impossible to disconnect from your job

I learnt that very early on. In my first full time job, my boss got mad at me for arriving at the office at 9:05, unacceptably late.

So precisely when my hours were done I'd stand up and leave.

> talk directly to them, be professional but not mean, and tell them what and how they can improve

And then get reported to HR… my advice is to be the 1st one to do the backstabbing and complain that it is impossible to work with them.

> Get used to being in meetings for hours

Working from home helps… one can cook and build lego during meetings.

View on HN

I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality.

Estimating things you've never done is hard.

Estimating things you've done a lot is trivial, and pointless.

When people saying that estimating is hard, they don't mean they easy kind.

"I want you to build a document management system, how long will that take?"

Uhhhhhhhhhhh....

"It will take me X weeks... to come up with a reasonably accurate estimate."

It will take 2 months to gather the actual requirements and be able to do an estimate.

This guy consults.

From my experience, the two months of gathering requirements will be more valuable than developing something from zero requirements. Whatever you code with always be "wrong" because with zero requirements there is nothing to test against.

the correct answer is 'yes'

Fork an existing one, slap your name and logo on it. 2 points.

Exactly. We'd love it if more people did that with our document management system. (https://github.com/formkiq/formkiq-core)

"This is git. Have fun!"

Estimate are for accountability. It's for team management. That's why middle management shouldn't have access to estimates imho.

The issue everyone is skirting here about estimates is the unknowns. Letting management know what the unknowns are and how confident you are you can resolve them is just as helpful as providing an accurate hour estimate.

Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a software project are similar to a promise that my trip to the store will only be 15 minutes which I’m held to even if I notice the low fuel gauge.

I like the store metaphor.

Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do.

But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.

Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.

Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done.

Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.

> the above estimate will be either 30 minutes

Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions.

I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”)

Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake.

I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise.

-------

> depending on my audience

Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for!

(Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)

I think the reason that estimating is hard is that no one ever returns to their estimates and tries to fix the estimates. What usually happens is that people throw out a number, mismanagers think that number is negotiable, and whether the project's completion is in any way related to the estimate - the estimate is forgotten.

No one writes down "this is why I think the project will take X [time units]".

And no one goes back to that estimate and says "I left Y & Z out of that estimate, I better include that next time."

If you want estimates that have any relation to reality, your estimating process needs to have that sort of feedback.

> When people saying that estimating is hard...

I think they're referring to the sort where management negotiates the estimates, like you're haggling over something in the marketplace. If they have such a strong opinion about how long something should take, then asking you for estimates is setting you up for failure and blamestorming. "It’s one banana, Michael. What could it cost, $10?"

I've streamlined the process, and just say that anything will take five days to complete.

Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur.

Also, on the negotiation side of time it will take, I absolutely know for myself that I can code things fast and functional but a bit hacky, or beautiful and elegant and will take much longer.

The negotiation should be about when to do which.

At a higher level, you put your teams together within their temperaments in mind and match that to the work.

Some code will be a nexus of changes and interaction with other code (invest early), and some code will get written once and never seen again (go fast and forget).

One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch".

The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.

In my experience writing out assumptions together with estimates tends to improve estimate accuracy a lot, by challenging the assumptions (and estimates) more at estimation time, and making it more visible when changes occur at implementation time that impact estimates.

As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.

One of the most productive teams I worked on spent time at the end of an iteration to look back on our previous estimates and re-estimate them. We got much better at estimating the remaining work we had, and knowing whether we would hit deadlines or not.

My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue.

It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?

Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.

If you're being asked to estimate a task without insufficient information on what the task is, punt it back with 'More information needed, we'll look at it 3 weeks from now in the next sprint planning'.

Accurate estimates are impossible, but you can get better at them. Getting better at them mostly entails increasing your estimate to the point that it feels absurd, and then doubling it. To become a true expert, double it again. Another approach is to always bump it up a unit of time. So an hour becomes a day, a day a week, a week a month, a month a quarter, etc.

Really, you just have to be a pessimist. Instead of saying what people want to hear (it's simple and can be implemented quickly), you need to imagine the long-tail worst-case scenario where everything that can possibly go wrong goes wrong, then give that number. If people don't give you a somewhat incredulous look when you give an estimate, you probably were too optimistic. Just remind them that you're imagining a worst-case scenario and say that you hope to have it done sooner, but don't back down on your estimate.

Another thing to realize: at the business level, deadlines are often picked arbitrarily to create urgency. The specific date of the deadline is usually less important than just having some deadline, any deadline, to motivate everyone. Business people will pretend the deadline is Very Important, but it's all an act, more or less (arguably it's a necessary one). Remember this when giving your estimates.

> Accurate estimates are impossible

disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.

No matter what the task is, things can go wrong that you didn’t anticipate.

Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee…

Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.

yeah, and maybe I'll have a heart attack and die while going to take a piss but that doesn't imply it's impossible to accurately estimate that it's going to take 5 minutes for said piss.

What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so.

There has to be a name for the type of reply your post represents.

Haha yes, webpack breaking or a test failing is equivalent to having a heart attack or a meteor hitting your kitchen.

if your webpack or ci/cd pipeline is breaking often enough that you worry about it when delivering estimates, that's a you problem.

Are free ponies available in this magical land you speak of where nothing ever unexpectedly breaks? Please put me down for two.

you mean the same world where no one has heart attacks and meteors have never hit houses?

Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing.

If your shit is breaking so often you're afraid to give an estimate, that's a you problem.

And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.

Software has an unusually fat long tail, to an even worse extent than real engineering. The probability of something unexpected popping up and inflating the time something takes by an order of magnitude is much, much higher than the likelihood of the same happening while cooking.

This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.

Well said. 50th percentile vs. 90-99th percentile estimates is a great way to put it.

I'm going to repeat what I said to another poster.

If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem.

I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't.

Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.

Not quite sure how you found your way onto a tech forum without any understanding of what software development entails, but unlike carpentry, where every time you want a new wall the carpenter needs to go through the same process to make the wall, or in cooking, where every time I want a roasted turkey the cook needs to cook a turkey, software almost never does the same thing twice. If you find yourself doing the same thing twice, that's a tool problem.

That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.

> software almost never does the same thing twice

odd, because my experience is that your CI/CD pipeline does the exact same thing repeatedly.

Perhaps the answer to your confusion about my experience is that I don't suffer tools that hamper my productivity.

Put it another way.

I ran a raiding guild for several years and about halfway through that stint I recruited a player that raised the bar for what I thought was possible. Perhaps you need your bar raised.

> Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before.

This is too real.

[Managers] are like children. They want everything right now, and they want it their way. But the secret is to give them only what they need, not what they want. — Montgomery Scott

> I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality.

Which is why you'll get better at estimating as you get more years of experience under your belt, and why estimating is something that seniors are better at than juniors.

Even after 20 years you may never have hooked in new library X, but I'd be willing to bet you've done something kind-of similar, and your estimate will be more accurate than a person with 1 year of experience and has never done anything remotely similar.

> Estimating things you've done a lot is trivial, and pointless.

Keep in mind you are not providing the estimate for the person who has done the task many times, you're providing the estimate to people who have never done it before. So for them, it absolutely is not trivial.

> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.

As far as what the system actually tells you your job is: it's not to do good work, it's to be perceived as doing good work. This is an important distinction.

Notably, promotion in orgs makes demonstrating non-programming skills more important than anything else. Communicating a lot, and well, is likely a much faster route to a better title and better pay than digging into fiddly technical problems and saving the day that way.

You see a mediocre junior come in and carve a shockingly-fast path up the promotion ladder without ever getting good at programming—they're communicating better, and probably, especially, a lot more. The most-visible get promoted. Talk more, email more, message more, speak up in meetings more, call more meetings. Make yourself prominent in anything process- or architecture-related. It doesn't even need to be productive (most of that stuff's not).

The sad truth of how to get paid more in most orgs.

Also "redesigned the ui moving all the menu entries" trumps "we are now much faster and save a lot of aws money"

Yes! Figure out a way to make what you did visual, or nobody will care. Front end tasks are better to take than back end, because you don’t have to do extra work to produce a demo that’s not just text and numbers (and minor GUI changes still beat all but the most impressive benchmark graph, among many crowds). Factor the extra time-cost of this (sometimes more than the time it takes to do the actual work) into your estimates, when you can.

As a bonus, people who know nothing about programming, ux, or design, want to weigh in on UI. This provides a natural opportunity to have positive interactions with them, which is a very good thing. Ask if they want to have another meeting to go over their concerns one-on-one.

To be fair, the best team leads I have had were all far from the strongest developers on the team.

The best team leads job isn't to dev, it's to represent the teams interests to the larger organization, and I have known some people who have really gone to bat for us, while at the same time barely being able to code genuinely getting angry at CI for pointing out obvious problems with their code.

Count yourself lucky.

I hope there are a few in-between steps between "strongest developer" and "actively destroying what others are doing"

Dude I don’t know. Representing the team means understanding and making sure the architectural approach and interfaces/contracts with other teams are solid and will stand the test of time. This is certainly different from leetcode skills, but I’ve never seen a truly bad coder have any success at it.

If they aren't the best developer but realize that then it isn't a problem - it's when you have someone who is terrible and thinks that they're great!

If by team lead you mean manager, sure. If by team lead you mean tech lead, absolutely not. They should be one of the strongest developers on your team.

> How long does it take you to go to the store? Yes you might die in the process and take ∞ time, but one normally considers common inconveniences in this. A senior who can't estimate isn't a senior.

The problem tends to be that, a lot of the time, you aren't told what store nor what mode of transport you have. Or you're told both, but the store you were told to go to doesn't have what they want so you need to go to another store.

In my experience, being able to estimate is about both

- Being able to give an idea as to how long it will take given a list of assumptions, AND

- Being able to highlight what the risks are that can cause it to take longer, and how much longer. Those risks sometimes include the fact that your assumptions were wrong in some way; and sometimes include lots of other things (dependencies, etc)

> His code is not elegant, it barely works, requires constant full rewrites, is an endless source of segmentation faults, deadlocks, sleep() in the main thread and whatnot.

A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader.

Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance.

Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business.

Not testing your code though. Places that value that shit speed at any cost eventually go bust, it is not smart and indicates a dumb culture which probably carries over to strategy and financials. That has been my experience. There is a basic level of standards. No need for architectural astronauts or monad fanatics but some sanity!

> There is a basic level of standards.

I agree with you, and it's very simple to define such a level: use as much discipline as you need to ensure shipping features at an acceptable rate in the long term.

Too much polishing lowers your release rate. Too little discipline will hurt the "in the long term" part.

Thats a good way to put it. Shipping value rather than features though. Which is represented as long term shareholder value, but within some kind of ethics (don’t fuck the customer type stuff).

Thinking in terms of value could mean you sometimes suggest weird things like removing features, cancelling WIP (sunk costs) etc. when appropriate. Or spending way more time polishing than seems necessary or conversely getting something out that looks way too quick and dirty. There are cases where no tests are OK despite what I said but usually MVP stage stuff where no market fit exists yet.

"Places that value that shit speed at any cost eventually go bust"

That has not been my experience...

Have you experienced just speed. Or speed at any cost? I.e. releasing really buggy features that customers complain about and churn on? Obviously with enough VC and marketing dollars anything could be possible.

> A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader.

But the functionalities don't work and generate customer support load…

I should perhaps mention the time he compiled a binary on his machine, committed it on github and went on vacation. And then we couldn't fix the bug that needed urgent fixing.

> Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance.

We do have customers yes.

> Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business.

You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?

> But the functionalities don't work and generate customer support load…

And this is the first issue you should have mentioned! All the rest is peanuts...

> You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?

I'm not defending him. I'm just refuting that a developer's competency can be judged without taking into consideration, first and foremost, the benefits he produced for the users of his software.

Shipping broken, especially code that looks ok but it secretly broken - is far worse than having no code at all. Once it's in place, it gets dug in like a tick, and if it's a pile of poor assumptions and wrong logic, you're in a much worse spot than you were with a clean slate.

If everyone else is spending all their time cleaning up the broken shit he built but won't fix, and he continues to produce more broken shit faster than everyone else can keep up with fixing it, he is a 10X programmer. Not because he's actually 10X better, mind you - he just makes everyone else 10X slower.

Corollary 3: This is one reason why many businesses deliver one product and then sink without a trace.

Corollary 4: Never buy version 1 of anything.

4.1.00175-update3: Never buy version x.1 from a company that never ships version x.0 of anything.

This kind of company is often run by people who think "People don't buy x.0 because they're afraid of bugs, so always ship x.1 as though we fixed the bugs." while failing to actually do the QA to earn that version bump.

Which predictably results in customers refusing the company's x.1 because, in their own words, "I'm not going to pay to be their beta tester.".

> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.

You can't choose your colleagues, but you can choose your company. Some of them have fair evaluation processes and try hard to avoid biases. Same thing for meetings, not all companies/teams have long meetings.

"If you can't change the organisation, change the organisation"

Or change your own perception.

I don’t think this is completely true. There’s a limit to how often you can force yourself to run the interview gauntlet.

> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.

don't blame the player, blame the game.

without the player there will be no game. blame the player.

I disagree with this statement in general. Institutions/nature (the game) cannot be held accountable. Persons can be. If we want to change the world, it starts with changing the behaviour of individuals, slowly changing the institution.

The person who needs to change their behavior is the hiring decision person. The player is just making the best of his situation. The fact that the game is running means the most likeable person will be promoted, even if they aren't liked much.

The players should cooperate to not end up with someone bad for the players being promoted.

When there is no rulebook, definitely blame the players.

I'm only learning to play correctly in mid-career. No amount of being good at technical stuff will get you promoted in most orgs—maybe to mid-tier dev levels, but not much higher. Being hyper-social, will. Not the normal amount of social you need to be to do a good job as a developer, but spreading out your "footprint" on purpose so you're known by and often interacting with a lot more people, even if those interactions are actually a drag on overall productivity. I've learned from observing others who are good at doing a lot of talking in meetings, and who eagerly start adding shit to people's calendars and stuff their first week. It fucking works. Reliably. Be bold, and be noisy. Get promoted.

Do you really want to be promoted?

I certainly don't, I'm fine where I'm at (software architect).

A senior who can't navigate the politics around estimating is missing key skills. But they still can't estimate. To estimate something you have to know what you are building and the steps to take to build it in advance. Senior engineers usually don't have enough political weight to stop that changing half way through a project and therefore cannot provide estimates. They can estimate hypothetical scenarios that are unlikely to happen.

It's called "estimation" because it's not supposed to be precise.

Of course the only way to obtain a precise measurement is to start the clock and do the thing.

And yet in the politics of a company, an estimate becomes fact, and then if you don't meet it they are angry.

Am I the only one who watched star trek?

Estimate, multiply by 4, give the number.

It will take 4 units of time, time units are subjective.

I dont know if you are joking but when managing i do exactly that and that work (with a factor of 3 to be precise, with most people, some aldready take that into account). Works also with myself, i askmyself 'how much i think it will take, i double it and i assume half the day i will be bothered by other unplanned things'. It work remarkably well especially for longer projects.

https://www.youtube.com/watch?v=t9SVhg6ZENw

I was always told to multiply by pi. Results that are not round numbers look more thought-out.

Much like estimates, pi is irrational

And pi squared if it is a new team doing something new...

There's a three-pronged approach when dealing with it:

- Pad.

- Communicate risks.

- Communicate assumptions.

Then when assumptions are wrong, immediately communicate that this will change the estimate. When risks hit, communicate that a risk hit, and whether or not you can absorb the impact in the planning. If not, communicate the expected delay. Pad that too.

Communicate, communicate, pad, and communicate.

(Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)

If you still get in trouble for missing estimates, pad more and communicate in writing. Then when people start blaming, you can point to the emails sent. To their/your boss if necessary.

> (Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)

This. It helps to realize that when someone asks "how long will X take". What they are actually asking is "When can I rely on X being done by?". If you say 2 days and it takes one, no problem. But if you say one and it takes 2, they've already told the client it'll be done tomorrow, arranged for the machinery to be in place, and now everything is jammed up based on your delay.

Estimating is as much art as science and requires understanding the context around the estimate and how it will be used.

also offer alternatives, preferably at the same time you communicate the risk. When the risk hits you can then start making recommendations about the workarounds you've already communicated.

This stuff is fluid but too many technical people feel as if it's not.

> I've overheard a team lead claiming they are completely impossible.

How big was the team? What were their responsibilities?

I have worked places where, because of bad management, we dropped everything to shift to other tasks so often that it was nearly impossible to estimate anything.

team of 4 including himself.

They seem to have a lot of spare time and work on toy projects often.

Lego during meetings. Now there's a good idea. I'll take that one away as good advice!

Remember Rule 10: Soft skills over technical skills. I'm sure the team lead has some qualities.

I told a guy I mentor this once. You can make a career out of only knowing the right people and you can make a career out of only knowing the right things. The situation you want to be in though is knowing the right people AND knowing the right things. That’s where the real money is.

The only skill he has is sucking up to his boss.

> After writing countless emails to convince him to fix his code, and wondering why they wouldn't just fire him and save everyone else some time

I do wonder whether this was escalated, to either the previous team lead, some other manager, or just a shouting match in the corridor.

Eventually my team lead asked me what was going on (he probably had gotten complaints about me breaking the tests).

I told him what I had done (which is easy to show in a git show commit_id) and I guess he responded to them saying that we would not revert the change.

In general I prefer to not have in person discussions for conflicts, so that there is a trail left behind, and I can take hours to respond, so I don't get heated up.

> After writing countless emails to convince him to fix his code, and wondering why they wouldn't just fire him and save everyone else some time, the CTO announced that the guy was now promoted to team lead. :)

It is. commonly known that some good developers make poor leads. Could some poor developers make decent leads?

After all, most serion management has never seen an if-clause, are they any better than this guy?

Maybe. But if the accounting is accurate, this person refused valid, and urgent criticism. They refused all input, and eefused to care that there was an issue.

This would make a very poor team lead. Imagine this person taking the wrong path, then refusing to acknowledge so. Imagine them upset that "their" path was being constructively criticized.

This is how companies go bankrupt, how months or years of work result in garbage.

Maybe thats exactly how management acts in this firm?

They looked at complaints about this dude's behaviour and go "clearly one of us!" ^^

Oh yeah the account is accurate.

At some point I had to use a C library written by him.

Due to segmentation faults I decided to just rewrite it by myself (in less than 200 lines).

He holds a grudge against me because of that.

When I showed with benchmarks that a sleep() in a loop in the main server thread is not a great idea he said "don't fix what isn't broken".

djamn, this is painfull

He gets promoted = double click cv.doc and get updating for me. Team leading is about people but fuck you need some level of competence. Infact I say you need more technical skill in some ways to be across everything. How will this TL have high standards if he short circuits his unit tests and then fiercely argues for it?

He doesn't have standards. Last time I had to do with that team, the only test the code had passed was "it compiles".

Surprisingly, it didn't work.

>> the only test the code had passed was "it compiles"

He might be really good at type systems!

With Haskell, if it compiles then it works. But not for the reason people think. If you spent the time learning Haskell, you probably are smart, conscientious and thought quite hard about your program.

That said type obsessed people invent things like property based tests (basically fuzzers for math people). They test the shit out of their code!

If you call "void*" a type :D

Have you tried changing companies? That sounds like a very toxic environment.

Last time I tried that I ended up in a company that was full of racists… I had to leave in a couple of weeks.

I think there's a lot of wisdom to the old adage "birds of a feather flock together".

I would almost add another point to the list of 10 points: Your worse software engineering colleagues will often get promoted to do something else. Expect them to become your team lead.

>> The test contained a "return true" before the actual test.

And he could find the same amount of deficiencies in your own code. You can always find something if you search hard enough.

You can always find deficiencies. But some code is objectively worse than other code, sometimes massively so.

>And he could find the same amount of deficiencies in your own code.

I'm amazed how many people in this thread seem to believe that it's literally impossible for one dev to be less competent than another, let alone by a significant margin. John Carmack is objectively a better developer than me, and by a huge amount, but I don't feel ashamed or like a lesser person because of it.

> if you search hard enough

Thing is, I don't search at all. I just find them because they stand in the way of me doing whatever it is that I'm supposed to be doing instead of debugging his code.

Also, when people find a bug in my code (which does happen, naturally) I don't spend weeks trying to gaslight them into thinking there really is no bug. I just fix it :)

> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.

Matt Levine wrote another epic LOLfest about a similar topic yesterday. [0][1]

I recommend subscribing to his column as the email is always full length piece without the paywall.

[0] https://www.bloomberg.com/opinion/articles/2023-11-07/bridge...

[1] https://archive.ph/CQUn9

Is there something wrong with archive.ph lately? I only get infinite captchas. Yesterday same thing on another article. It was a great service when it worked.

Edit: seems to be an issue with DNS over HTTPS, change provider from cloudflare to nextdns solved it (per https://www.reddit.com/r/AskTechnology/comments/162w00q/gett...)

> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.

This is some bullshit that losers subscribe to.

Reply on news.ycombinator.com