4 ms·

You're summing up a pretty wide spectrum of things as "distrust". If a junior engineer says they understand what I'm asking for and will deliver it in 2 weeks,

You're summing up a pretty wide spectrum of things as "distrust". If a junior engineer says they understand what I'm asking for and will deliver it in 2 weeks, but actually they don't fully understand and will deliver half of it in 3 weeks, I wouldn't typically characterize that as them lying or being untrustworthy. But it's a problem that's a lot easier to detect and solve in person. (It's also, not coincidentally, a problem that Linux kernel devs generally don't need to worry about - there's no Linux Dev Inc. whose next big contract will fall through if a project doesn't finish on time.)

29athrowaway 3y ago
"I give deadlines to junior engineers who don't understand things." Ding, ding, ding! You have won the toxic bingo. If you work with 2 week deadlines you've lost control of your project. Like in Tetris.
- SpicyLemonZest 3y ago
  It's quite rare to have the degree of control you're envisioning over a project. Most software teams are building products to sell to customers, and most customers aren't going to accept "IDK whenever we're done" as an expected delivery date. Companies can and should provide some degree of wiggle room, but it's not realistic to expect that you can avoid ever thinking about how long a task is going to take.
  - 29athrowaway 3y ago
    That sounds like you are totally winning! If everything is urgent, that is a strong symptom that you completely lost control and you should not be running a project. The value you add as a decision maker is making decisions that mitigate the risk of being in a scenario where everything is urgent, that is, a crisis. If you are constantly in crisis mode running for your life because you failed catastrophically.
    - SpicyLemonZest 3y ago
      I’m not sure why you’re being so hostile here. I agree everything can’t be a crisis, and if there were a way to have people in the office only when something important is happening, I think quite a lot of companies would go for it. But you can’t set remote work as the standard and then announce that there’s crunch time in July so everyone has to come in 5 days a week.
      - 29athrowaway 3y ago
        Because the primitive and irrational need to hurry all the time for no reason is what takes 99% of the satisfaction of building software while making software worse. Remote work is the future, and irrational environment-ruining offices are the past.
        SpicyLemonZest 3y ago
        Again, there are many important reasons - it sounds like you're just too isolated from this to understand the context you're missing. You should find one of your customer-facing coworkers and sit in on a call some time if you'd like to learn.
        29athrowaway 3y ago
        You tell engineers that only you understand the customer, then tell the customer only you understand the engineers. But truly speaking you understand neither. It is just a sweetspot of information asymmetry, pseudoscience and falsehoods. The days of middle management are counted. Everyone wants middle management and their endless excuses for not having hard skills gone. If you are micromanaging you don't understand software and don't understand management.
        heleninboodler 3y ago
        > You tell engineers that only you understand the customer, then tell the customer only you understand the engineers. I have people skills, god damn it!
jay_kyburz 3y ago
2 week deadlines is way to long for a junior. I would be reading and discussing a juniors code every day. Even mid level programmers should be reporting progress every day. 10 working days of code is a hell of a lot of code.
- 29athrowaway 3y ago
  The expectation of producing high volumes of code in short cycles is a red flag. Programming is not data entry. Programmers are not typists. Programmers make progress by creating building blocks that can be reused later. In 2024, many of those building blocks already exist in the form of libraries. If there's no reusability, everything is a special case, there's duplicate code, your program maps 1:1 to your data... there is a good chance you have a problem creating abstractions. In that case, the junior is you, and you are not the right fit to be a mentor. If you see a constant need to micromanage people, that is a symptom a highly insecure personality that is unsuitable for management, or trust issues, or poor recruiting skills, or poor delegation skills (matching the tasks to the wrong skills). All of those are signs that you may not be ready to be a manager. Micromanaging will just stress and demoralize your workforce. If someone is unreliable enough to need a conversation every day, either you or that person should not work there. And if this is the case for every junior engineer in the team, and the situation persists for long periods of time, the likely reason is that the problem is you.
  - jay_kyburz 3y ago
    I think you misread my comment, or perhaps our definition of high volumes of code is different. Perhaps junior means something different. I also suspect what I consider "good communication" you consider "micromanagement". I like reading and talking about what my colleagues are doing every day. I'm interested. I learn new things, and sometimes I teach others a trick or two. Sometimes I tell them I don't like something and we agree to disagree. Sometimes the requirements change, and that need to be discussed as well. Sometimes I just like hearing and sharing stories about things that didn't work out. Yesterday I spend a whole day profiling to try and work out why we are leaking so much memory. I didn't work it out, but I can tell my colleagues what I tried and what I will try next. The point I was trying to make is that a solid 8 hour work day is a lot of time, and I think everybody should have something interesting to say about what they did.

29athrowaway 3y ago

"I give deadlines to junior engineers who don't understand things." Ding, ding, ding! You have won the toxic bingo. If you work with 2 week deadlines you've lost control of your project. Like in Tetris.

SpicyLemonZest 3y ago
It's quite rare to have the degree of control you're envisioning over a project. Most software teams are building products to sell to customers, and most customers aren't going to accept "IDK whenever we're done" as an expected delivery date. Companies can and should provide some degree of wiggle room, but it's not realistic to expect that you can avoid ever thinking about how long a task is going to take.
- 29athrowaway 3y ago
  That sounds like you are totally winning! If everything is urgent, that is a strong symptom that you completely lost control and you should not be running a project. The value you add as a decision maker is making decisions that mitigate the risk of being in a scenario where everything is urgent, that is, a crisis. If you are constantly in crisis mode running for your life because you failed catastrophically.
  - SpicyLemonZest 3y ago
    I’m not sure why you’re being so hostile here. I agree everything can’t be a crisis, and if there were a way to have people in the office only when something important is happening, I think quite a lot of companies would go for it. But you can’t set remote work as the standard and then announce that there’s crunch time in July so everyone has to come in 5 days a week.
    - 29athrowaway 3y ago
      Because the primitive and irrational need to hurry all the time for no reason is what takes 99% of the satisfaction of building software while making software worse. Remote work is the future, and irrational environment-ruining offices are the past.
      - SpicyLemonZest 3y ago
        Again, there are many important reasons - it sounds like you're just too isolated from this to understand the context you're missing. You should find one of your customer-facing coworkers and sit in on a call some time if you'd like to learn.
        29athrowaway 3y ago
        You tell engineers that only you understand the customer, then tell the customer only you understand the engineers. But truly speaking you understand neither. It is just a sweetspot of information asymmetry, pseudoscience and falsehoods. The days of middle management are counted. Everyone wants middle management and their endless excuses for not having hard skills gone. If you are micromanaging you don't understand software and don't understand management.
        heleninboodler 3y ago
        > You tell engineers that only you understand the customer, then tell the customer only you understand the engineers. I have people skills, god damn it!

jay_kyburz 3y ago

2 week deadlines is way to long for a junior. I would be reading and discussing a juniors code every day. Even mid level programmers should be reporting progress every day. 10 working days of code is a hell of a lot of code.

29athrowaway 3y ago
The expectation of producing high volumes of code in short cycles is a red flag. Programming is not data entry. Programmers are not typists. Programmers make progress by creating building blocks that can be reused later. In 2024, many of those building blocks already exist in the form of libraries. If there's no reusability, everything is a special case, there's duplicate code, your program maps 1:1 to your data... there is a good chance you have a problem creating abstractions. In that case, the junior is you, and you are not the right fit to be a mentor. If you see a constant need to micromanage people, that is a symptom a highly insecure personality that is unsuitable for management, or trust issues, or poor recruiting skills, or poor delegation skills (matching the tasks to the wrong skills). All of those are signs that you may not be ready to be a manager. Micromanaging will just stress and demoralize your workforce. If someone is unreliable enough to need a conversation every day, either you or that person should not work there. And if this is the case for every junior engineer in the team, and the situation persists for long periods of time, the likely reason is that the problem is you.
- jay_kyburz 3y ago
  I think you misread my comment, or perhaps our definition of high volumes of code is different. Perhaps junior means something different. I also suspect what I consider "good communication" you consider "micromanagement". I like reading and talking about what my colleagues are doing every day. I'm interested. I learn new things, and sometimes I teach others a trick or two. Sometimes I tell them I don't like something and we agree to disagree. Sometimes the requirements change, and that need to be discussed as well. Sometimes I just like hearing and sharing stories about things that didn't work out. Yesterday I spend a whole day profiling to try and work out why we are leaking so much memory. I didn't work it out, but I can tell my colleagues what I tried and what I will try next. The point I was trying to make is that a solid 8 hour work day is a lot of time, and I think everybody should have something interesting to say about what they did.