23 ms·

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear t

• jakemal 6y ago
  I have never had anyone indicate to me that this is a problem. However, every time I spend days on a problem that ends up being a trivial number of LOC, I get a feeling of anxiety that I am going to be seen as incompetent. That's been the case my whole career even though I know it's unfounded.
• ww520 6y ago
  Yes, it happens, quite a lot.
• l0b0 6y ago
  So far I've worked in one place which didn't use version control in 2007, one place which had reluctantly started using version control just before I started in 2010, several places where automated tests were considered pure waste, where everybody had full access to production, where backups were untested, where one or two people held crucial knowledge which was not shared with anybody else, etc. The real world moves a hell of a lot slower than best practice.
  • musingsole 6y ago
    Devil's advocate: or best practices are rarely incentivized...because there's little to connect them with real, tangible value in an organization. Having fully linted, automatically tested code doesn't matter if the product isn't valuable and useful. And if the product is truly valuable and useful, it likely would be as well in the absence of these practices.
    • Piskvorrr 6y ago
      Fair point. I did take a week's tally of "how much developer time did we burn on hunting for backups and rogue edits", and suddenly SVN was orders of magnitude more attractive (ages ago).
• greggman3 6y ago
  I probably can't tell this story correctly because it is 2nd hand but ... I was on a browser team. A fellow co-worker decided to add the Fullscreen API to it which means not just add the API but first discuss it in the relevant standards committees. I'm pretty sure he thought, and so did management, this would be a 2-3 month project at most. IIRC though it was like 18 months, maybe longer. Some problems that aren't obvious at first * What is fullscreen mode? Is it a mode for the page, a mode for an individual element? What? They eventually decided it was for an individual element * What happens to the CSS above that element when none of its parents are being rendered? I'm sure that took a while to argue over. Like if it was position: relative or absolute and suddenly it's parent is no longer displayed. What if the parent has CSS transforms? Okay, you say we ignore those and consider it the root element. Okay so does that mean none of the other styles from the parents apply like color or font-family? If some do and some don't we now have to go through every CSS property and decide if it does or does not continue to inherit. I don't actually know the answer to this. * You have a DOM A->B->C->D->E. C asked to go fullscreen. While there E asks to go fullscreen. User presses ESC or whatever to exit fullscreen. Should it pop back to C or A? Does it matter if E is a video element and they clicked fullscreen? What if C is an iframe does it matter? * Testing across all devices that support it requires all new testing infrastructure because going fullscreen is effectively something that happens outside the page not inside so testing that it actually happened, that a user can actually exit it correctly, requires entirely new test systems that were not there for previous APIs. Then multiply by 5 at least (Windows, MacOS, Linux, Android, ChromeOS, ...) And so even though I'm sure everyone ended up understanding that, it turned out to be way more work than anyone expected. Yet, in the back of their minds it was arguably always "this is taking way longer than it should, goals not met" or at least that's how it seemed to be perceived.
• Piskvorrr 6y ago
  Last time I met this, it was 2008 IIRC.
• RandomInteger4 6y ago
  This scenario seems like something that's more common in freelance work where the client has access to the code for whatever reason.
• decebalus1 6y ago
  You'd be surprised...
• birdyrooster 6y ago
  I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
  • toast0 6y ago
    That skeezy company [1] at least has a fairly clear review process; it's clear what they will reward. It's not clear how what they reward is related to things that are useful to ~users~ people, advertisers, or the business, or even not breaking everything by rushing to push at the end of the review period. If you care about those things, you either have to not care about your reviews, or enough review positive stuff that you have a little time to do real work. [1] Unless there are multiple skeezy companies in Menlo Park.
    • thakoppno 6y ago
      Menlo Park has Facebook and Robinhood connected by Willow Road.
  • skrebbel 6y ago
    For readers who, like me, don't keep track of SF Bay area municipal borders: I looked it up on Wikipedia and that skeezy company is likely Facebook.
  • 0xEFF 6y ago
    It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.
    • deleted 6y ago
      [deleted]
    • tehjoker 6y ago
      The ceiling is the size of the addressable market.
• cek 6y ago
  I'm a maintainer of an OSS project with other contributors. I have fights like this all the time because others are constantly just wanting to fix the symptoms. This is for a project that is a framework/API, where the saying "the best programmers remove more code than they add" should be even more true.
• archi42 6y ago
  I regularly hear a friend complain about BS like this and variants. "Why did adding a button take a week, it's just a button?!" is also very popular. Not sure what's worse, that or the recurring "that element should be 1px to the left, drop everything you're working on and fix it asap"...
  • silveroriole 6y ago
    A funny side-effect of this that I ran into: customers who went to tortuous lengths to avoid requesting a new page or button, because they’d had that past experience of ‘just a button’ taking 2 weeks. They still wanted all the new functionality, but glued onto the existing pages/buttons because they thought it would save time! An interesting misunderstanding :)
    • MBCook 6y ago
      See that all the time. It’s why you need proper requirements gathering, to get past that kind of thing.
  • touristtam 6y ago
    Try changing the colour and getting told it isn't the same shade of red as the drawings presented by the designer on his PDF presentation.
    • flukus 6y ago
      "It looks different on my iPad, we need it to look exactly the same everywhere" No, No you don't.
    • detaro 6y ago
      I mean, that's totally reasonable if that's the spec (not to mention hopefully trivial to fix). Now if there's 5 drawings with different colors, or asking "what color do you want it?" leads to a 5-week email chain...
      • 6y ago
• seneca 6y ago
  You would hope so, but I've seen an Engineering Director at an otherwise well run software company use number of Github commits as the central reason to put someone on a performance improvement plan as recently as 2019. Granted, this was someone who was a professional manager and hadn't been an engineer for the last 90% of their career, and many people were shocked by it, but it happened.
  • kevsim 6y ago
    I was wincing a bit when I made my initial comment fearing I might actually be wrong. This hurts to read.
  • majormajor 6y ago
    Were they right about the person being a low performer? I'm curious if this is "everybody knows this person isn't doing any work, here's a blindingly obvious metric to use to defend this move to HR" because HR orgs often hate things that don't have metrics attached, or if it's "I don't understand what this person is doing, and I don't see any commits, so it must be nothing"?
    • seneca 6y ago
      Completely valid question, and I think you make a great point here. A lot of baffling managerial behavior is because the manager is working in a baffling bureaucracy. Unfortunately, I think this situation was largely of the latter case, and maybe some motivations I'm not aware of. They were a senior engineer that spent a lot of time coaching the rest of the team, and less time on their own personal work. The commits data point, in my opinion, should have been the beginning of a conversation that ended with the manager asking this person to adjust their priorities. Instead it was presented as an accusation that the person wasn't getting their work done, which ultimately lead to them feeling insulted and quitting.
      • Aeolun 6y ago
        Yeah, I’ve been in this situation before (without the PIP), where I had to explain to my manager that I can either help everyone get their work done, or do my own work, but given the number of people asking for help it was not going to be both.
• WalterBright 6y ago
  Many people assume their manager knows what the employee is doing. They often aren't, meaning they go by what they can see, which is lines of code. The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you. Especially if you are WFH.
  • kevsim 6y ago
    That’s true. And I guess depending on the job/manager you could replace lines of code with “user-visible changes to app”, etc.
    • csharptwdec19 6y ago
      I've seen that abused all the way to management, where meaningless new features are prioritized ahead of bugs
    • qayxc 6y ago
      That'll be exploited as well. The number of pointless UI and feature changes would skyrocket without the app actually getting better or gaining meaningful functionality. Meta-metrics might be much more helpful, though harder to come up with, quantify and monitor. Things like defect rates, user reported incidents, user satisfaction, stuff like that. Things that cannot easily be gamed from within the development process and that are still directly linked to the success and economic viability of the product and its development methodology (though on a higher level).
      • kevsim 6y ago
        I wasn’t suggesting that as a good metric. More like “if isn’t LoC, it’ll be some other terrible metric”
  • drocer88 6y ago
    Rather than an integer number of lines of code, how about using a boolean : "it works" or "it does not work"? or "Does it meet the spec" or "it does not meet the spec"? Even a mediocre manager should able to test that one out. Code is often improved by removing code.
• deleted 6y ago
  [deleted]
• cortesoft 6y ago
  A lot of software development still happens at businesses that are not 'software companies'. The experience is very different, with a much different culture around software.
• trav4225 6y ago
  One would wish. Personally, I don't think I've ever worked under a manager who understood software development. It tends to be all about what they can see (GUI) or about nearly meaningless metrics on a dashboard (LOC, tickets closed, etc.). Again, just in my personal, limited experience.
  • dgb23 6y ago
    The problem is not "manager/client doesn't understand software development". That's fine. The problem is lack of trust in you as the expert and possibly a lack of self-awareness (they think they understand). A manager/client should make mostly strategical decisions like: We should solve this problem, here are the resources. And almost never tactical. They also shouldn't even care or look at LoC. They shouldn't be worried about metrics of 'effort' at all.
    • csharptwdec19 6y ago
      Bingo. My leader isn't a technical person by a long shot. Instead they focus on getting people that they can TRUST on their team. Yes, sometimes it means we have to go back and 'fish' for metrics to throw the business. But we do notice that the less we chase metrics (and, yes, the arbitrary goals set out by the company as a whole) the more productive we really are.
    • trav4225 6y ago
      Ah, agreed. I guess that, in my experience, not understanding SW development tends to go hand-in-hand with not trusting the developer. I found your phrase "lack of trust in you as the expert" a little jarring because (again, in my personal experience) considering the developer to be a domain expert is somewhat of a foreign concept. I suspect/hope the situation is better elsewhere in the industry. :-)
      • dgb23 6y ago
        I meant 'expert' as in the person responsible for the technical side. Not in the sense of 'they know everything they need to know all the time' or anything like that. > I suspect/hope the situation is better elsewhere in the industry. :-) I do freelance, client work. Alone and in (very?) small teams. Typically my/our clients only have a superficial understanding of everything technical (if at all). Trust often needs to be earned. One way to gain trust is being creative/optimistic and explaining feasible possibilities and strategies. Another one is being pragmatic and not selling them something they don't need, or might not need. And then the most important one is to have conversations about their problems and wishes. Showing that you understand them by asking questions and writing a specification. And explaining your (iterative) workflow: "Let's figure this part out after we've done this other part." I guess this is the "domain" part of the process. My experience is that if trust is in danger then the work is less valuable, less fun and less sustainable. Indications of this are things like we discussed before and similar: - Trying to measure effort instead of rewarding value. - Nitpicking, bikeshedding and other distractions. - Overstepping their expertise (typical for UI design, a bit less for programming) Now most of my interactions are good but sometimes I get the above. We're actually discussing of doing more upfront communication work in the offers and initial discussions to prevent these things (even by filtering out clients/collaborators) and to set a tone. Because again, this is unsustainable on multiple levels and it never ends well...
• alexbanks 6y ago
  Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all. In 2014 I worked at a company that switched to Git and then started measuring LoC to assess performance/involvement. Engineers took to committing/removing things like node_modules directories to make the data meaningless. It still happens, even today, quite a bit.
  • MBCook 6y ago
    My company has just started to use Git in the last year. No timeline yet on when existing projects (like mine) will be migrated. I agree with you 100%.
    • Aeolun 6y ago
      You can start using Git now right? Just wait for them to catch up.
  • arthens 6y ago
    > Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all. Spot on. Talented engineers can usually be picky and change job if they don't like the environment, but not everyone has this option. There's plenty of developers who are stuck in shitty companies (lack of skills/experience, or struggle with interviews, or just live in places with limited opportunities). And the longer you stay in a bad place, the harder it gets to escape it. 2 years ago I was the hiring manager for a few open positions and I was honestly shocked by some candidates. So many "senior devs" that despite having 5-10 years in the industry wouldn't have passed the interview even if they applied for a junior role. It's very easy to have a distorted view of the industry if you are privileged enough to have only worked in great tech companies. I'm guilty of this myself, making friends with other devs in my city was definitely eye-opening for me.
    • around_here 6y ago
• VLM 6y ago
  At most of the big companies I worked at (over 500 employees) there is a steering committee doing prioritization work and continuous integration test suites and an elaborate change control committee and process such that fixing a spelling error will take much more than two days. Whats nice about the proceduralism is you can document that the steering committee only meets once a week on Tuesday afternoons and change control meets on Thursday. And everyone knows the automated test suite on DEV takes about half a working day. So if a change can't be worked into the schedule in less than a day, it'll never pass CI testing before the change control meeting so it'll take more than a week. Whats bad, is mgmt would like you to complete multiple changes perhaps at the same time which always complicates the change control process especially if change #7 failed last week so company policy is to roll everything back and now we have 13 changes, two weeks worth, to complete next weekend. Also whats bad, is knowing its a corporate nightmare to make any change, why did I make a mistake to begin with of having the buttons swapped or a misssspelling or whatever. I find the big metric now a days is backlog. Lets see the number of request tickets decrease this week instead of increase. That leads to intense pressure to roll multiple problems into one ticket.
• fireflux_ 6y ago
  Oh, very much so. I don't think it's a matter of how "old" the industry is - there will always be people who have never worked with software folks or are familiar enough with the ecosystem not to make the assumptions stated in the article. This made me realize that working in a purely engineering team can sometimes be a perk. Not because technical people are "better", but because it leads to fewer frustrations like this one.
• beefield 6y ago
  > Do people actually have fights like this with management at their companies? There was a time when I thought this video was funny: https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
  • NateEag 6y ago
    I used to think that was hilarious. These days I can only look at it and think "the expert is terrible at calm confrontation and good communication. There would be no problem if he had developed those skills."
    • _ph_ 6y ago
      I have to agree. Of course the requests in this sketch were obviously silly and not doable when taken literally. But my experience is, that the requestor of a new feature often has big problems communicating that request. It could be that the requestor describes something, which sounds almost as silly and contradictional as those seven lines, the actual request is something different, which actually makes sense. But just is completely badly communicated. It is important to rule out miscommunications. Contradictions often are not obvious to the requestor. It also helps to understand, which of the contradicting requirements can be dropped to resolve the problem. Sometimes the problem is just a small feature which made it to the requirements, because no one considered it a problem. That doesn't mean, I haven't gotten requests which were as silly as in the sketch and had discussions along the lines shown :) And of course, I never hesitate to speak up about actual issues.
    • Aeolun 6y ago
      That has to come from two sides though. The people in this sketch are clearly not interested in listening to what the expert says either. Getting sensible requirements is not only on the expert.
      • NateEag 6y ago
        Sure. Both sides need to have good faith. But the expert is the one who can know if the requirements are sensible. In requirements gathering, the whole job is to hear people's attempts to describe their problem and figure out what problem they actually have. By definition they don't have your expertise, or they wouldn't need to talk to you. So, of course they will say contradictory things and use terms completely incorrectly - they cannot do anything else. That's why they hired you. The expert in this scenario gets hung up on their incorrect language and gets flustered and stymied, telling them "What you want is impossible!" What they _said_ is impossible. It's our job to persistently, patiently, calmly help them understand their needs, without judging them for needing our help. I'm not particularly good at it, but I understand the mission.
• duderific 6y ago
  They don't always make the comment out loud, but you can tell they're thinking it. They absolutely use lines of code metric at my company. I don't miss any chance to tell my manager it's complete bullshit. His answer: "Engineers are supposed to write code, just like construction workers are supposed to build houses."
  • ptx 6y ago
    What if the construction workers just stack all the windows in one corner and pour all the concrete in the other? It must be just as good as building the house properly since they used the same amount of materials. If they just double the amount, the resulting pile of garbage will be twice as good as a functioning house.
  • csharptwdec19 6y ago
    "Okay. And when 5 years down the road you discover it's 10x as expensive to replace the floor joists. Why? Because you based the builder's performance on how many materials were in the house and as a result the piping in the basement is an overdone rats nest anyone maintaining the home has to work around."
  • WrtCdEvrydy 6y ago
    Set prettier on VS Code to make each line one character long on commit. Rebase your code on your branch after done and run it. It took 23 minutes for that rule to dissappear after my lines of code metric jumped 250,000k
  • bavila 6y ago
    What an absurd response from your manager. If you give a construction worker a design to build a wall, and the worker is given 2,000 bricks that must be used to build the wall, then, yes, of course the worker must lay down all 2,000 bricks to build that wall. However, if I am asked to build a computer-simulated model of said wall, and if there is a way to build the model with 200 lines of code that looks and performs identically to a model built with 2,000 lines of code, then, yes, of course I am going to build the wall with 200 lines of code. I hope you find better pastures.
• ajford 6y ago
  Not everyone has good managers. $JOB-2, admittedly about 4 years ago now, the good manager with a background in software left for a better opportunity and was replaced by someone who's background was management. With no insight into the subject matter, they fell back on whatever they thought they could quantize. Got numerous things like that, though my team lead and our project manager did a great job of shielding the team from that crap, we still occasionally hear it come up in group meetings and the like. I even got a task handed directly to me, bypassing everyone above me, to "estimate how much it would cost to migrate all those linus apps your team has to windows. They'll run better there". Just the windows licenses alone would have cost us about half the existing server costs since we were using AWS instances. Also included a line item that included recruitment costs for a new developer, and verbally informed him that it would likely involve hiring a new team, as the existing team was hired specifically as linux developers.