15 ms·

they have innate understanding that being observed working is more valuable than the results of their work. I've seen coders who knew this by heart forget this

• aeternus 7y ago
  I've seen this as well, in my experience much of it comes from other orgs that see the engineering team come in late, or walk around the office tossing a ball into the air. They start putting pressure on engineering managers to make sure their team is "working". Their team clearly needs more discipline and those 'slackers' need to be cut. What they don't see is that the engineer tossing the ball figured out that the solution they were about to spend 2 weeks coding can be achieved by leveraging an existing library requiring only a couple days effort.
  • grepthisab 7y ago
    > What they don't see is that the engineer tossing the ball figured out that the solution they were about to spend 2 weeks coding can be achieved by leveraging an existing library requiring only a couple days effort. Maybe this is an unpopular opinion, but that wouldn't mean that the engineer shouldn't implement in a couple days and then work on something else. HN loves the trope of the super smart engineer who is smarter than _everyone_ and can look like they're doing nothing.
    • logicchains 7y ago
      The engineer probably isn't going to get paid any more for finishing it faster, so what incentive do they have?
    • NoodleIncident 7y ago
      You don't have to be a "super smart engineer" for that situation to occur. It's completely normal for software features to shrink (or grow) by that much time in my experience.
• org3432 7y ago
  I've seen that, and the opposite as well, where you have a huge team of people constantly working and yet mysteriously nothing gets done and managers aren't sure what people are doing on a day to day basis.
  • noonespecial 7y ago
    The managers could walk over and ask them. If you create a system to measure butt-time in a seat coding, you're going to get lots and lots of butts in seats coding. This may not necessarily result in a product.
    • davinic 7y ago
      "The best example of the danger of focusing on a single measure came when I first started my own consulting practice in California. My second client was in the fast food business and had a chain of fried chicken restaurants that was growing in both the U.S. and internationally. .... Roy went on: “The one metric that is really important to management is Chicken Efficiency. At the end of every day, I have to calculate my Chicken Efficiency score...this is the measure that all the managers talk about all the time.” Looking at Roy’s chart it looked like he was achieving 99-100% Chicken Efficiency every day that month that must be good. However, I still didn’t know what the measure entailed. Roy explained: “Chicken Efficiency is basically a scrap measure. You take how much chicken you cook and divided it the number of pieces of chicken sold. If you sell all the chicken you get 100% chicken efficiency, which is the goal – no waste or scrap.“ When I asked Roy how he achieved near perfect Chicken Efficiency every day he answered: “I’m gonna let you in on a secret, but don’t put my name in the report saying you heard this from me. My secret is I stop cooking chicken around 7:30 and only cook to order after that. That way none of the chicken sits under the lights for too long, everyone gets hot and fresh chicken, and I don’t throw any of it away – 100% chicken efficiency.“ I asked, don’t you get people coming in here all evening until the restaurant closes? Roy replied: “Oh yeah we get tons of kids coming in here after baseball or soccer practices or games, families, and lots of people. I tell them I’m going to make their chicken to order and it will take 15-20 minutes.” I asked, do most of them wait? Roy answered: “Heck no, they file right out the door and head off someplace else, but management doesn’t measure that. They do want to make sure I don’t throw any chicken away every day, however. My buddie Leon taught me this trick – he got promoted to run three restaurants by not cooking any chicken“. I went on to visit other restaurants and every one of them talked about the importance of Chicken Efficiency. Source: https://corporater.com/en/the-chicken-kpi-be-careful-of-what-you-measure/ https://corporater.com/en/the-chicken-kpi-be-careful-of-what...
• Iv 7y ago
  It is easier to track people being at their desks than diving into the git repository and looking at what got done. Also, for a programmer who did not code for 5 years because they got into management, it is a huge source of anxiety and forces them to contemplate the obsolescence of their skills. Having to ask a junior dev how to compile the project you are supposed to overwatch can be felt as humiliating. When I had a team to manage, I tried to keep involved enough so that I could do the whole build process. Most of my work was complaining about broken master branch and regressions, praising the correct person when a feature gets implemented, shout with the higher management to stop adding irrelevant features every time they meet a client and have a weekly discussion on how things are going on. We had one lay off during that period, on my recommendation. I was worried about the team morale, but got told we should have fired that person earlier.
  • repomies691 7y ago
    > It is easier to track people being at their desks than diving into the git repository and looking at what got done. Why not both? Time tracking with tomsething like toggl doesn't take much effort, and you can combine that with reviewing git activity.
  • neilv 7y ago
    Why would you feel humiliated for not knowing which button to press to build, on the current bullpoop, if you hadn't yet needed to use that particular bullpoop? It's possible that a junior dev who showed you the button might then joke to other junior devs about you not knowing. But a smarter junior dev, wise beyond their years, will realize it's just bullpoop trivia, one of thousands of bullpoops one has to pick up and later discard in favor of a fresher bullpoop, and be happy to help. In any case, you, as an experienced person, should know it's just a different flavor of bullpoop, and not the most valuable thing anyone knows. Your decision to stay in the loop, with the bullpoop that your team is currently enjoying, sounds like it might come in handy. But I wouldn't want anyone to ever feel humiliated over bullpoop.
    • Iv 7y ago
      I totally agree, but many people feel that way, especially if they got into a higher position because they are supposedly more knowledgeable. A build process is one thing, knowing C++17 or rust is another. Knowing if refactoring all these templates structures was really worth 2 weeks is something that is hard to ask to a junior dev.
• rlayton2 7y ago
  "I can be trusted, but I can't really trust others"
  • boohoojangles 7y ago
    unfortunately, quite common.
• jrockway 7y ago
  I know exactly how it happens. Engineering projects take a long time. 90% of the effort lives in the basement where nobody can see it; getting data from some other system, optimizing queries, spinning up the servers... nothing at all user-facing. So to the untrained eye, 90% of the time, programmers are doing nothing. And that 90% can be weeks, months, even years. I don't think any of this is unique to software engineering, either. You don't just one day decide to build a bridge and show up at the bank of the river with a cement mixer tomorrow. To someone that wants to drive over the river, it looks like no progress is being made on the project. Hence, lots of meetings (delaying the project further) to make sure everyone is working hard enough. (Because there is always "that one guy" who actually isn't doing anything. And it looks the same as someone who is working hard to an outsider.) As for why we spend money hiring people that don't actually do anything, tracking the progress of other people's work... I think it's just loss aversion in action. If you spend 10% of the day working on timesheets and pay an additional employee to check up on them... you know where your money's going. But if someone just shows up to work and does nothing, then they're stealing from you and must be punished! It is human nature. I don't know what we did in the past that's different from today. Somehow we got to the moon. But now companies are so bloated that even doing nothing seems like it requires 30,000 employees. I don't have much hope for the future generation of megaprojects. And, you know, we're not really doing them anymore. I wonder what changed. Or maybe looking back at the all the achievements of the entire human race at once makes it difficult to put the present day into perspective.
  • raverbashing 7y ago
    To be honest I still can't understand how those big megaprojects got out of the ground with people coordinating by face to face meetings, circulating memos and phone calls Maybe that's part of the secret, communication was more expensive so you wasted less time with noise But how do you put a switch on the panel of the 747, make the wire go all the way to the tail of the aircraft and make it do what you need it to do?
    • TomMarius 7y ago
      My suspect is distraction. People used to be able to deep work regularly.
• blowski 7y ago
  Because managers also have managers. If the managers at the highest level think developing software is pretty similar to packing widgets in a factory, they understand and want to see the Frederick Windsor Taylor school of management in the engineering department. For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices. But every time there’s a problem, you compromise and it creeps a bit more in the direction of ‘command and control’. And all those little changes add up to the results you observe.
  • dmix 7y ago
    This is why I'll never work for anything but smaller startups. That sound awful and counter to how software should be done. I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.
    • repomies691 7y ago
      > I'd imagine the smart developers quickly get replaced by the obedient clock-punchers. I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well? I have personally also tracked time on my personal projects. While not sure if it does bring much value, it is not a huge investment time-wise.
      • carlmr 7y ago
        I think that's not the point OP is trying to make. There's nothing wrong with tracking time for yourself, or clocking in and out of work. Time however is a really really bad measure of productivity. If somebody constantly stays late at work because they never finish stuff on time, in our current culture they often get promoted for being hard workers. While some might do the same job in 2h that they do in a month. So what the super productive guy learns after a while is that they just need to "work overtime" and delay presenting results to get ahead. If this attitude starts pervading your team the productivity might start tanking too.
• whytaka 7y ago
  Managing people without means that you have to keep track of your employees’ mindsets individually and communicate to each one accordingly which is exhausting.
• repomies691 7y ago
  Personally I don't really see why following some quite common work schedule like 8:30 - 16:30 and having daily stand-up meetings destroy morale. Of course depends on the details, but my life has always been quite nice following standard work styles. Time tracking is a chore that not many like, but still it takes in my experience only 15 minutes or so from the daily time and IMO produces pretty good value.
  • mdtusz 7y ago
    The issue that many developers have with time tracking is that it requires you to either translate your work into management speak in order to appease the management, or write what you're actually doing and have tons and tons of small blocks in your time tracker that make you look like you're being unproductive and trying to obscure something. Both options add unnecessary mental overhead and interrupt any possibility of having a "flow state". Writing code and working on software is not a linear process, so writing "worked on feature X" for your entire morning may be accurate, but it's not fine grained enough for what the managers want to see and it doesn't really serve any purpose at that point when you already have daily stand-ups and sprint meetings every week. This likely isn't the case at all companies and with all managers, but I suspect many have the same experience I've described.
• iLemming 7y ago
  Problem with programming - a solution always looks easier when it is already done. Even when a programmer solves a problem, he/she looks at the problem and the solution and thinks: "I have no idea why it took me whole day, it should've taken maybe an hour.". Also, sometimes it's dangerous to leave a programmer alone with the problem - you don't know what they are doing until it's too late. That is why even the best soloists should try pair/mob programming from time to time. And it is essential to increase visibility in the teams where people work solo/distributed teams. It's okay to shout out in a public chat, group email, etc. of what you're doing, what approach you're going to try, things that unclear to you, what's left, how you'd like to improve it, etc. Don't be afraid to look stupid. It's better than trying to come up with excuses later. Post diagrams drawn on the napkin. Ask your teammates what would they think if you add a library, or remove one. Delayed feature for unknown and speculative reasons never looks good, delayed feature backed-up with your publicly shared notes is always better. Better for you, better for the team. The best teams operate that way and if a manager cannot create a culture of complete transparency, they'd loose the ability to trust their peers.
• topaxi 7y ago
  Optimizing numbers looks productive..
• arethuza 7y ago
  Well, managers typically have their own managers and will be under pressure to demonstrate how they are "managing" - I think a lot of these things are done to "manage up" from one level of management to another.
• avip 7y ago
  Maybe the same way we don't stop for hitchhikers N years (N < 5) after obtaining a driving license.
• jamiethompson 7y ago
  As I developer who accidentally climbed the ladder into management (and eventually bailed) I can say that from my own experience it is by sheer force of pressure from non-technical management above oneself. I fought the management culture hard for a few years, eventually realising that I needed to either become one of them, or quit. I quit.
  • boohoojangles 7y ago
    Did you quit being a manager or the company? (Honest question). From my observations, it is rare to work for someone as a manager and not succumb to upper management pressure.
    • jamiethompson 7y ago
      I quit being a manager but kinda sideways stepped into a different senior (non management) role in the same company/department. I was quite lucky because I didn't really want to leave the company at the time. I just didn't want to be on the trajectory I was on. It was kinda awkward initially, mostly for the people I had hired and been manager of who I was now colleagues with, but not for long. Hands down it was one of the best life decisions I've ever made. I feel as though the experience I gained helps me to perform my current role even better than I would otherwise be able to as I have an appreciation of the politics above me that I'd not have had I not been up there and back down again the way I have.
      • boohoojangles 7y ago
        I am glad you could make this transition in the same company. I've recently had to step down from a senior non-management role (tech lead) that my company forced into management tasks into it, specially things that no one else wanted to do. It didn't work and I ended up leaving the company. It was hurtful because I left believing I had a lot to contribute and was motivated too.
        • jamiethompson 7y ago
• jrvarela56 7y ago
  tl;dr Trust/anxiety The dynamic goes like this: 1. The manager is responsible for team's output/metrics. 2. Metrics are driven by improvements to the product. 3. Software functionality is hard to estimate (not a widget factory as other comments mention). 4. Manager gets anxious as it will be judged by an outcome not entirely within control. 5. Knowing everyone is putting their best effort increases confidence that team will reach goals by which the manager will be measured. The manager evaluates team members on longer intervals depending on past performance. This allows the manager to course-correct before the team is evaluated. The seniority/past-performance of a team member determines how much the manager trusts them to spend the team's resources (time; man-hours) to accomplish the team's goals. The brute force approach to make sure people aren't slacking is watching them work/check-in/report on progress. You can quickly tell if someone isn't putting an effort after a couple of standups/reviews with less-than-expected output or 'yet another excuse'.
• Double_Cast 7y ago
  "Seeing Like a State" discusses legibility vs illegibility, and how centralization incentivizes legibility. E.g. like how units of measurement were standardized in order to mitigate tax evasion.
• boohoojangles 7y ago
  "It is easier to justify project delays to upper management when everyone in the team comes in on time, otherwise it becomes my liability as a manager". One good friend of mine, who I respected as engineer, after becoming engineer manager in a small company (less than 10 engs).
• granshaw 7y ago
  I can understand requiring the team to be present/online during a certain chunk of the day, so that meetings can be had and people are around if others need help or need to coordinate, but, time tracking for FTEs!? I can only see the most unemployable of Engineers putting up with that shit.
• C1sc0cat 7y ago
  Quite why people think morning stand-ups make sense - as most people are going to have long commutes it makes much more sense to do stand ups at the end of the day. Actually this is how RAD /DSDM stand-ups are supposed to be done -at the end of the day so everyone knows what they are working on tomorrow.
• aswanson 7y ago
  I quit a prior gig because of this. A job I was working on for a few years brought in new management and they started nanomanaging every code commit. After 3 years of building trust, I felt the contract had been broken and quit with nothing else lined up but faith in my abilities. Turned out well.
• sgt101 7y ago
  I think that technology disruption is one of the roots of this. I'm talking about minor disruptions like a new GUI library or an improved query algorithm. Diffusion of these is somewhat uneven, and this results, occasionally, in senior management seeing projects that were impossible or very hard in the past suddenly delivering. This makes them believe that other similar projects should also deliver in that way and that if they aren't then something is wrong - leading to a desire to find out what's going on in minute detail.
• segmondy 7y ago
  Their leaders keep pressuring them and saying, "I don't see your team working!!! What are they doing? Why are they not in at 8am? I want to see some BUTTS IN THE SEATS!" After they get 1 or 2 bad reviews, they realize that one way to get a raise as a manager is to have the team look super busy. No matter how much your team delivers, if they make it lose easy, folks think it's easy! If they are running around, sweating, stomping out fires, looking seriously stressed, then my gosh they must be working really hard. :-(