4 ms·

Tbf to u/cj, there's a few things you mentioned that would lead one to believe you aren't fulfilled with your job (which, I think, is an important distinction f

by bumby 3y ago

Tbf to u/cj, there's a few things you mentioned that would lead one to believe you aren't fulfilled with your job (which, I think, is an important distinction from being 'happy' with one's job). If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it. Sure, pay is an important part, but they also really value aspects like a sense of purpose, the camaraderie of working on a good team, and being able to meaningfully contribute, amongst others. "One day the fucks will run out." You say this as a point about disconnecting, but you can disconnect while still "having fucks" about your job. Your life doesn't have to revolve around your job, but I don't want to work with a bunch of people who don't really care about what they are doing. You talk about how you spend remote meetings doing other not-work-related things. I get that meetings can be boring or of little value at times. In those times, ideally, I would prefer someone be honest and say the meeting is of little value and go do something more productive. At the least, I would like them working on something of value to the group while occasionally checking in. You wouldn't act this way in person, so I don't understand why you think it would be ok to do so remotely, other than it's because you can get away with it. Again, that makes it more transactional than contributory. I could go on with the other points, but all that is to say, I don't think u/cj was completely off with their comment.

dasil003 3y ago
I was going to make the same points. Some of these are frustrated and cynical dismissals that may represent reality sometimes, but are counterproductive when taken axiomatically. For instance, “estimates are lies” fails to acknowledge that planning must still be done in the face of uncertainty, and engineering is the best equipped to do this. The last thing you want is for the pointy hairs to just start pulling deadlines out of thin air. But recognize it’s not about putting in time, it’s about helping the business plan and setting up the team to build things the right way. If you do this well, everyone wins, but it does require the ability to work smoothly with people who don’t share your same expertise and not treat them like idiots.
- codr7 3y ago
  Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort. Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished. https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=QVBlnCTu9Ms
  - dasil003 3y ago
    Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you. But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in. As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.
  - bumby 3y ago
    To your point, most planning is bad. That doesn't mean planning is worthless when done right. It seems that most bad planning fundamentally misses the interactions between different tasks (ie it largely treats the different tasks as independent). A probabilistic approach that correlates the tasks seems to work better. Sometimes estimates are made out of ignorance or borne from an optimism bias. But sometimes they are lies, because its easier to get a project funded based on a misrepresentation, and keep it funded once the initial cost is sunk.
bluefirebrand 3y ago
> If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it. Having a fulfilling career is a myth sold to you by employers. Focus on getting paid enough to have a fulfilling life instead. After all, chances are the higher ups at your company will fire you at the drop of a hat if they think it will secure them a bigger year-end bonus.
- ruszki 3y ago
  Except it’s not necessarily. As a software developer, you have the privilege to not really care about money if you don’t want to. I didn’t have money problem, ever. Without even trying. I can fly three times between Europe and America, and about 20 more times inside the continent in a year, and I can still put about third of my salary to saving. And I live in a country now where software developers are heavily underpaid: Austria. Most of my friends in other fields can’t even imagine my life - their exact words.
  - bluefirebrand 3y ago
    > As a software developer, you have the privilege to not really care about money if you don’t want to. That sounds nice for you, but your experience is not common I don't think. It's certainly not my experience as a software developer in Canada, where I struggled for years and even now make "just" a comfortable living. I'm very happy I don't have to worry about rent and groceries and I can save quite a bit, but I'm certainly not able to "not care about money"
    - cartoonfoxes 3y ago
      HN has a high concentration of above-average salaries, even within the US. It's tough constantly hearing how many multiples more my southern equivalent at FAANG is earning without it affecting my sense of self worth.
      - bumby 3y ago

by bumby 3y ago

dasil003 3y ago

I was going to make the same points. Some of these are frustrated and cynical dismissals that may represent reality sometimes, but are counterproductive when taken axiomatically. For instance, “estimates are lies” fails to acknowledge that planning must still be done in the face of uncertainty, and engineering is the best equipped to do this. The last thing you want is for the pointy hairs to just start pulling deadlines out of thin air. But recognize it’s not about putting in time, it’s about helping the business plan and setting up the team to build things the right way. If you do this well, everyone wins, but it does require the ability to work smoothly with people who don’t share your same expertise and not treat them like idiots.

codr7 3y ago
Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort. Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished. https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=QVBlnCTu9Ms
- dasil003 3y ago
  Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you. But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in. As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.
- bumby 3y ago
  To your point, most planning is bad. That doesn't mean planning is worthless when done right. It seems that most bad planning fundamentally misses the interactions between different tasks (ie it largely treats the different tasks as independent). A probabilistic approach that correlates the tasks seems to work better. Sometimes estimates are made out of ignorance or borne from an optimism bias. But sometimes they are lies, because its easier to get a project funded based on a misrepresentation, and keep it funded once the initial cost is sunk.

bluefirebrand 3y ago

> If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it. Having a fulfilling career is a myth sold to you by employers. Focus on getting paid enough to have a fulfilling life instead. After all, chances are the higher ups at your company will fire you at the drop of a hat if they think it will secure them a bigger year-end bonus.

ruszki 3y ago
Except it’s not necessarily. As a software developer, you have the privilege to not really care about money if you don’t want to. I didn’t have money problem, ever. Without even trying. I can fly three times between Europe and America, and about 20 more times inside the continent in a year, and I can still put about third of my salary to saving. And I live in a country now where software developers are heavily underpaid: Austria. Most of my friends in other fields can’t even imagine my life - their exact words.
- bluefirebrand 3y ago
  > As a software developer, you have the privilege to not really care about money if you don’t want to. That sounds nice for you, but your experience is not common I don't think. It's certainly not my experience as a software developer in Canada, where I struggled for years and even now make "just" a comfortable living. I'm very happy I don't have to worry about rent and groceries and I can save quite a bit, but I'm certainly not able to "not care about money"
  - cartoonfoxes 3y ago
    HN has a high concentration of above-average salaries, even within the US. It's tough constantly hearing how many multiples more my southern equivalent at FAANG is earning without it affecting my sense of self worth.
    - bumby 3y ago