8 ms·

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" befor

by guappa 3y ago

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.

siva7 3y ago
Remember Rule 10: Soft skills over technical skills. I'm sure the team lead has some qualities.
- chasd00 3y ago
  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.
- guappa 3y ago
  The only skill he has is sucking up to his boss.
pjc50 3y ago
> 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.
- guappa 3y ago
  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.
donatj 3y ago
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.
- fjfaase 3y ago
  Count yourself lucky.
- guappa 3y ago
  I hope there are a few in-between steps between "strongest developer" and "actively destroying what others are doing"
- dasil003 3y ago
  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.
- roland35 3y ago
  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!
- PH95VuimJjqBqy 3y ago
  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.
ClumsyPilot 3y ago
> 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?
- b112 3y ago
  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.
  - ClumsyPilot 3y ago
    Maybe thats exactly how management acts in this firm? They looked at complaints about this dude's behaviour and go "clearly one of us!" ^^
  - guappa 3y ago
    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".
    - ClumsyPilot 3y ago
      djamn, this is painfull
fjfaase 3y ago
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.
2-718-281-828 3y ago
> 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.
- nikolayasdf123 3y ago
  without the player there will be no game. blame the player.
- stcg 3y ago
  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.
  - psds2 3y ago
    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.
    - rightbyte 3y ago
      The players should cooperate to not end up with someone bad for the players being promoted.
      - justincredible 3y ago
        [dead]
- speed_spread 3y ago
  When there is no rulebook, definitely blame the players.
- hotnfresh 3y ago
yodsanklai 3y ago
> 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.
- sam_lowry_ 3y ago
  "If you can't change the organisation, change the organisation"
  - 28304283409234 3y ago
    Or change your own perception.
- Aeolun 3y ago
  I don’t think this is completely true. There’s a limit to how often you can force yourself to run the interview gauntlet.
nanidin 3y ago
Have you tried changing companies? That sounds like a very toxic environment.
- guappa 3y ago
  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.
  - shiroiuma 3y ago
    I think there's a lot of wisdom to the old adage "birds of a feather flock together".
bobmaxup 3y ago
> 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.
- guappa 3y ago
  team of 4 including himself. They seem to have a lot of spare time and work on toy projects often.
baz00 3y ago
Lego during meetings. Now there's a good idea. I'll take that one away as good advice!
jnsaff2 3y ago
> 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/bridgewater-had-believability-issues https://www.bloomberg.com/opinion/articles/2023-11-07/bridge... [1] https://archive.ph/CQUn9 https://archive.ph/CQUn9
- bondarchuk 3y ago
  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/getting_an_infinite_captcha_loop_on_archiveis_and/ https://www.reddit.com/r/AskTechnology/comments/162w00q/gett...)
pif 3y ago
> 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.
- quickthrower2 3y ago
  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!
  - pif 3y ago
    > 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.
    - quickthrower2 3y ago
      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.
  - 3y ago
quickthrower2 3y ago
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?
- guappa 3y ago
  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.
  - EVa5I7bHFq9mnYK 3y ago
    >> the only test the code had passed was "it compiles" He might be really good at type systems!
    - quickthrower2 3y ago
      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!
    - guappa 3y ago
      If you call "void*" a type :D
roenxi 3y ago
> 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. 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.
- guappa 3y ago
  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.
  - porker 3y ago
    And yet in the politics of a company, an estimate becomes fact, and then if you don't meet it they are angry.
    - guappa 3y ago
      Am I the only one who watched star trek? Estimate, multiply by 4, give the number.
      - Hikikomori 3y ago
        It will take 4 units of time, time units are subjective.
      - GaelFG 3y ago
        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.
wccrawford 3y ago
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.
- orwin 3y ago
  Estimate are for accountability. It's for team management. That's why middle management shouldn't have access to estimates imho.
  - sixothree 3y ago
    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.
- Clubber 3y ago
  "I want you to build a document management system, how long will that take?" Uhhhhhhhhhhh....
  - saalweachter 3y ago
    "It will take me X weeks... to come up with a reasonably accurate estimate."
  - guappa 3y ago
    It will take 2 months to gather the actual requirements and be able to do an estimate.
    - wheresthebeef 3y ago
      This guy consults.
RHSeeger 3y ago
> 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)
EVa5I7bHFq9mnYK 3y ago
>> 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.
- AnimalMuppet 3y ago
  You can always find deficiencies. But some code is objectively worse than other code, sometimes massively so.
- HideousKojima 3y ago
  >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.
- guappa 3y ago
  > 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 :)
gopher2000 3y ago
> 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.
hotnfresh 3y ago
> 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.
- guappa 3y ago
  Also "redesigned the ui moving all the menu entries" trumps "we are now much faster and save a lot of aws money"
  - hotnfresh 3y ago
    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.
deleted 3y ago
[deleted]

by guappa 3y ago

siva7 3y ago

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

chasd00 3y ago
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.
guappa 3y ago
The only skill he has is sucking up to his boss.

pjc50 3y ago

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

guappa 3y ago
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.

donatj 3y ago

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.

fjfaase 3y ago
Count yourself lucky.
guappa 3y ago
I hope there are a few in-between steps between "strongest developer" and "actively destroying what others are doing"
dasil003 3y ago
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.
roland35 3y ago
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!
PH95VuimJjqBqy 3y ago
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.

ClumsyPilot 3y ago

> 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?

b112 3y ago
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.
- ClumsyPilot 3y ago
  Maybe thats exactly how management acts in this firm? They looked at complaints about this dude's behaviour and go "clearly one of us!" ^^
- guappa 3y ago
  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".
  - ClumsyPilot 3y ago
    djamn, this is painfull

fjfaase 3y ago

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.

2-718-281-828 3y ago

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

nikolayasdf123 3y ago
without the player there will be no game. blame the player.
stcg 3y ago
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.
- psds2 3y ago
  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.
  - rightbyte 3y ago
    The players should cooperate to not end up with someone bad for the players being promoted.
    - justincredible 3y ago
      [dead]
speed_spread 3y ago
When there is no rulebook, definitely blame the players.
hotnfresh 3y ago

yodsanklai 3y ago

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

sam_lowry_ 3y ago
"If you can't change the organisation, change the organisation"
- 28304283409234 3y ago
  Or change your own perception.
Aeolun 3y ago
I don’t think this is completely true. There’s a limit to how often you can force yourself to run the interview gauntlet.

nanidin 3y ago

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

guappa 3y ago
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.
- shiroiuma 3y ago
  I think there's a lot of wisdom to the old adage "birds of a feather flock together".

bobmaxup 3y ago

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

guappa 3y ago
team of 4 including himself. They seem to have a lot of spare time and work on toy projects often.

baz00 3y ago

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

jnsaff2 3y ago

> 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/bridgewater-had-believability-issues https://www.bloomberg.com/opinion/articles/2023-11-07/bridge... [1] https://archive.ph/CQUn9 https://archive.ph/CQUn9

bondarchuk 3y ago
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/getting_an_infinite_captcha_loop_on_archiveis_and/ https://www.reddit.com/r/AskTechnology/comments/162w00q/gett...)

pif 3y ago

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

quickthrower2 3y ago
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!
- pif 3y ago
  > 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.
  - quickthrower2 3y ago
    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.
- 3y ago

quickthrower2 3y ago

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?

guappa 3y ago
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.
- EVa5I7bHFq9mnYK 3y ago
  >> the only test the code had passed was "it compiles" He might be really good at type systems!
  - quickthrower2 3y ago
    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!
  - guappa 3y ago
    If you call "void*" a type :D

roenxi 3y ago

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

guappa 3y ago
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.
- porker 3y ago
  And yet in the politics of a company, an estimate becomes fact, and then if you don't meet it they are angry.
  - guappa 3y ago
    Am I the only one who watched star trek? Estimate, multiply by 4, give the number.
    - Hikikomori 3y ago
      It will take 4 units of time, time units are subjective.
    - GaelFG 3y ago
      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.

wccrawford 3y ago

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.

orwin 3y ago
Estimate are for accountability. It's for team management. That's why middle management shouldn't have access to estimates imho.
- sixothree 3y ago
  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.
Clubber 3y ago
"I want you to build a document management system, how long will that take?" Uhhhhhhhhhhh....
- saalweachter 3y ago
  "It will take me X weeks... to come up with a reasonably accurate estimate."
- guappa 3y ago
  It will take 2 months to gather the actual requirements and be able to do an estimate.
  - wheresthebeef 3y ago
    This guy consults.

RHSeeger 3y ago

> 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)

EVa5I7bHFq9mnYK 3y ago

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

AnimalMuppet 3y ago
You can always find deficiencies. But some code is objectively worse than other code, sometimes massively so.
HideousKojima 3y ago
>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.
guappa 3y ago
> 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 :)

gopher2000 3y ago

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

hotnfresh 3y ago

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

guappa 3y ago
Also "redesigned the ui moving all the menu entries" trumps "we are now much faster and save a lot of aws money"
- hotnfresh 3y ago
  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.

deleted 3y ago

[deleted]