Right, but you are cynical and dispassionate. There is a world you could be working in a place where you are more passionate and less cynical.

(This could be more personality than experience though, so I agree it could be a misread)

After 30 years in the job, I say that the poster you're responding to is just realistic. I love my job. I love what I do, but it's worth remembering that it's just a job. There is so much more to life.

Amen to that. Work to live, don't live to work.

I am passionate about the things I'm interested in, not all the unnecessary fluff around them :)

Not everyone needs to be passionate about the day job. Being present, competent, and reliable is enough. I’d personally go on to say that it’s risky to put too much emotional investment into something you don’t own/control.

I prefer to invest my passion in things outside of my day job. Working is fine, but it’s a means to an end to fuel more meaningful things. We don’t live to work.

"I’d personally go on to say that it’s risky to put too much emotional investment into something you don’t own/control." Bingo! This is exactly what happened to me.

What I learned is that, even in a great environment where there was a ton of latitude to have ownership of technical details and even product details, it's still contained within the broader context of a business. That business has interest in the thing you're working on while it's a factor in creating value, and when it becomes time to change focus onto other things, it will generally do that without much hesitation.

I've been burned by this multiple times. Eventually it clicked for me in the way you phrased it. So I show up and do what I can, bring my expertise as much as I can, gauge where the limits of what I can provide are, and keep a healthy distance mentally otherwise.

One other note - you can still be passionate about software and not one specific day job. You can still work on other projects and explore ideas as much as you want. It's just that that's a separate thing from work. Dedicate time and space separately for that IMO.

> One other note - you can still be passionate about software and not one specific day job. You can still work on other projects and explore ideas as much as you want. It's just that that's a separate thing from work. Dedicate time and space separately for that IMO.

This is what I was trying to get at and you've phrased it beautifully. Thank you.

To say it's "personality" is a little passive aggressively degrading. These opportunities are not accessible or sensible to everyone all the time.

I think you misread my intent. I was saying it could be personality of cynicism (which is fine) and nothing to do with the job.

> There is a world you could be working in a place where you are more passionate and less cynical.

The idea that if you're passionate about something you won't have any complaints about it or enjoy it 100% of the time is unhealthy. Most people realize that there's always an element of 'grind' to any task. You could be the most passionate person in the world, but I can guarantee that something about your passion will annoy you slightly. That's just being human

I don’t disagree. Sorry I feel people have misread a lot more malice into my comment than I intended.

I felt sympathy for the OP not superiority.

I didn't pick up disdain or displeasure from your original message, and I didn't feel bad for you. I felt good for you! I thought "here's someone like me, who's making a decent living in a nice job, but who has a good sense of perspective and isn't getting caught up in the inane irrelevant trivialities of the tech workplace that are ultimately utterly meaningless." You can make a living doing something you enjoy without having to buy into every single aspect of a corporate workplace and without tangling up your identity with your job. Some of us work to live, and are happy doing that. It's not a failure to be not totally consumed with your career.

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.

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.

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

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.

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.

The point is they're always guesses, so we multiply by Pi or whatever to make reasonably sure we're not coming up short. But it's all a game, and everyone knows deep down inside that it isn't working.

>they're always guesses

Maybe it's so prevalent in SWE that most are jaded, but all it means is that we are pretty bad at modeling it or simply don't care. Other domains, like aerospace, have similar problems but have much better methods to arrive at more reasonable estimates (when they care). For example, [1] gets into joint cost/schedule estimating using a more data-driven method where you can put uncertainty around it. It certainly beats 'multiplying by pi.'

[1] https://www.nasa.gov/ocfo/nasa-cost-estimating-handbook-ceh/

Comparing to physical engineering doesn't make much sense to me.

Part of the problem is it's all virtual, so there are no limits; part is that we're always pushing the envelope in the complexity department.

Building the same software again with just a tweak or two doesn't happen very much, the reason we build new systems is often to try something so different that it's not feasible to adapt existing systems.

Most of the time we have no idea exactly what we're building until we get there, even the customers usually have no idea exactly what they want.

Imagine going to a car manufacturer and giving them the kind of specifications we usually get for software, I can assure you they wouldn't be able to give you a good estimate either.

Research is a better comparison. How long will it take you to build a fusion reactor? Depends, right?

There's a lot you've said here that I agree with, but I think we use it to arrive at different conclusions.

FWIW, I've worked in software, automotive, and aerospace. They are probably more alike than you may realize. Vague requirements are quite common. The link above has a section specific to software development, so I don't think it's fair to say it only applies to physical systems. I would characterize it as a systems approach, rather than domain-specific. It uses "WBS" or "work breakdown structure" to delineate tasks. That's an approach that is agnostic to the domain. So if you're working on a mechanical system you might have propulsion, deployment, and control surfaces. If you are working on a software system, it might be user interface, command & control, and data acquisition. But the applicability of the method is the same.

What I think you highlighted is that SWE is generally much less well-managed than other domains. Mechanical engineers often get vague requirements but implement much more standardized processes in their work to hone in those requirements, largely because the costs of jumping in and iterating are much higher. By comparison, software development is the wild west. Like you said, software is virtual, so people are lulled into complacency that they don't need a structured process because they can build and make tweaks cheaply. But what you point out isn't really that software development is inherently different, but just that it's not managed well.

I think your research comparison misses its mark. Research isn't involved with developing some end-stage product for a consumer. The 'product' of research is an experiment and every research project I've been involved with starts with an estimate of how much that experiment will cost and how long it will take. And that follows the same basic structure as any other development effort. Maybe it's an apt comparison for some yet-to-be-proven tech like self-driving cars, but it doesn't explain why most basic CRUD applications miss cost and schedule estimates. I think the answer is that most software development has a culture that isn't as well developed in process control.

And that's my point exactly, every new software system is an experiment. No one has any idea if it's actually going to work out, it's all plug and pray.

If estimating research projects is as much a thing as SW, it's just as insane.

Pretending we know something we don't is lying.

Projections is another thing altogether, let's say we let this run for a month and then we have another look and see where we are. Much more connected to reality than pretending we know where everything is going from square 1.

It’s not any more different than any new mechanical design. Every new car line or rocket design I worked on was an “experiment” just like every new software product. You seem to confuse engineering with mass production. They are two different things.

If you think you’ll get to do research without estimating cost and schedule, you won’t be a researcher for very long. Pretending you know something you don’t is bad project management. But what I’m advocating is estimating with transparency regarding uncertainty. Uncertainty can be quantified. Pretending software is some precious unicorn project that doesn’t have to follow any process is just rationalizing bad process management.

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

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.

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

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.

I think this is one of the major downsides of focusing on money as the primary part of a job. It can easily become a constant comparison, which has a natural way of making you miserable.

Wow, Toronto really seems a terrible place in context of cost of living.

Is it a myth if people have managed to do it? It takes some self-awareness and conscious decision-making, but it's certainly possible.

IMO, a focus on getting paid can lead you to optimize the wrong things in life, making fulfillment less likely than more. It has a weird way of changing your value system by changing what you focus your attention on.