What a pile of straw men. I can’t help thinking that, intentionally or accidentally, the childish presentation is making readers turn down their critical thinking.
Every one of those things, when not taken to the caricatured extremes of the story, has made me a better programmer. Learning Python and C. Focusing on getting good at one thing, at times even at the expense of helping others. Calling out bad things when they’re bad, and accepting the endemic badness I can’t change at the time. Adopting new things early.
Trying to be a real programmer has made me a better programmer. Looking at the human side of problems… it’s often the right thing to do, but by no means always. Sometimes the system really does encapsulate the important aspects, whereas looking at any one user’s face would lead you astray. I think the advice here is misleading at best.
Of course they’re strawmen. This is written in an attempt to emulate the little prince, a children’s book written with such a style in the first place. It’s a story, not a paper to be published on the best practices of engineering.
It’s not like reading books, trying frameworks, being an expert, ops person, or an architect is useless or a despicable goal. Pointing out errors is valuable, trying to improve is valuable, going technical is valuable, and so is staying up to date. But there is such a point, at least in my personal experience, where it becomes easy to forget why these things are valuable, where they become an exercise in futility on their own. They’re a burden driven by anxiety to perform or prove myself, rather than a healthier objective of performing something or improving myself. I personally have the habit of taking a good thing and pushing it too far, wrapping myself in it. Then I tend to err towards the caricature and have to check myself, making sure I stay more grounded.
And the human face to keep in mind is not always just a user’s. God help me jobs could get depressing fast in that case. It can be your team, peers, coworkers, someone you’re looking to help indirectly or not. And then again, this is only for feeling a more long-term fulfillment, in the case illustrated here.
There’s no doubt to me that focusing on the tech side of things only can be fun and extremely entertaining, but for me, it only lasts a while. I don’t think it’s a viable path for me in the long term. The satisfaction is not long lasting enough, and it becomes harder and harder to have it be a suitable replacement for working on something I perceive as actually worthwhile to someone else than someone reaping heaps of money off of it.
This story, to me, was about showing that disconnect that makes its way, in a lighthearted way.
And yet, I think that I’ve met every single one of those strawmen and have sometimes had to make a conscious effort to avoid becoming one; eg, ensuring that my constructive feedback was actually helpful in moving forward and not off-putting.
This is such a great article/story! I have nothing to add, but didn’t want all the comments to be negative when the content is so positive.
What a pile of straw men. I can’t help thinking that, intentionally or accidentally, the childish presentation is making readers turn down their critical thinking.
Every one of those things, when not taken to the caricatured extremes of the story, has made me a better programmer. Learning Python and C. Focusing on getting good at one thing, at times even at the expense of helping others. Calling out bad things when they’re bad, and accepting the endemic badness I can’t change at the time. Adopting new things early.
Trying to be a real programmer has made me a better programmer. Looking at the human side of problems… it’s often the right thing to do, but by no means always. Sometimes the system really does encapsulate the important aspects, whereas looking at any one user’s face would lead you astray. I think the advice here is misleading at best.
Of course they’re strawmen. This is written in an attempt to emulate the little prince, a children’s book written with such a style in the first place. It’s a story, not a paper to be published on the best practices of engineering.
It’s not like reading books, trying frameworks, being an expert, ops person, or an architect is useless or a despicable goal. Pointing out errors is valuable, trying to improve is valuable, going technical is valuable, and so is staying up to date. But there is such a point, at least in my personal experience, where it becomes easy to forget why these things are valuable, where they become an exercise in futility on their own. They’re a burden driven by anxiety to perform or prove myself, rather than a healthier objective of performing something or improving myself. I personally have the habit of taking a good thing and pushing it too far, wrapping myself in it. Then I tend to err towards the caricature and have to check myself, making sure I stay more grounded.
And the human face to keep in mind is not always just a user’s. God help me jobs could get depressing fast in that case. It can be your team, peers, coworkers, someone you’re looking to help indirectly or not. And then again, this is only for feeling a more long-term fulfillment, in the case illustrated here.
There’s no doubt to me that focusing on the tech side of things only can be fun and extremely entertaining, but for me, it only lasts a while. I don’t think it’s a viable path for me in the long term. The satisfaction is not long lasting enough, and it becomes harder and harder to have it be a suitable replacement for working on something I perceive as actually worthwhile to someone else than someone reaping heaps of money off of it.
This story, to me, was about showing that disconnect that makes its way, in a lighthearted way.
And yet, I think that I’ve met every single one of those strawmen and have sometimes had to make a conscious effort to avoid becoming one; eg, ensuring that my constructive feedback was actually helpful in moving forward and not off-putting.