5 ms·

I cannot disagree more strongly with this article and the attitude behind it. I mean, look at each of his points in turn: 1. His first two points, stripped of

I cannot disagree more strongly with this article and the attitude behind it. I mean, look at each of his points in turn: 1. His first two points, stripped of the irrelevant polemic, are the complaint that software is meant to help the business meet its goals. Well, obviously it is. Very few people are paid to build software as artistic expression; that's for personal projects. Software that doesn't meet a business goal is bad software, no matter how elegantly designed. 2. His third point is that when you're in an organization staffed by people with their own personalities and goals, you need to be able to communicate and negotiate and engage in all kinds of human interactions. People who call this "politics" dismissively, as the author does, and think that it is intrinsically bad should never have a job where they have to interact with people; stay a low-level code-wrangler. 3. His fourth point is... well, honestly, it's that he hates his job. Sorry. Most people don't, though. If I were him, I'd look for a different role. 4. His fifth and sixth points are that if you work on a team, you also have to work with teammates, who will have their own personalities and goals and interests, and you'll need to be able to communicate and negotiate and engage with them. Um, yeah. If you aren't willing to do this, you're going to be a terrible teammate, and this guy sounds like he would be one, with all the griping he does about the coworkers he hates. 5. His seventh point is about collective code ownership, which is about treating developers as collaborating equals rather than letting one person on a power trip control everything. This upsets him, because he's the guy on a power trip and he wants to control everything. 6. His eighth point is that management methodologies exist. He seems to think this is self-evidently terrible, rather than considering that changing management methodologies can make a huge difference to the success and happiness of a team, and that agile methodologies are much better than old-school command-and-control waterfall stuff in a ton of ways. 7. His ninth point is that you're not cynical enough, because you don't hate everything already, and he does, and that makes him a better person, and you should also join him in hating everything and everyone. This is literally toxic advice. Do not take it, and if it sounds reasonable to you, it's time for some soul-searching.

deleted 10y ago
[deleted]
vosper 10y ago
I couldn't upvote this enough. Also, come on, it's not like everyone doesn't have bullshit in their workplace. I've never heard anyone except software engineers be so self-righteous and pretentious about our supposed special value in the business. Disdain and lack of empathy for working with other human beings comes a close second. Edit, to add: This is by no means universal. I know and have enjoyed working with some very talented, humble, and empathetic engineers, too. I don't think most programmers have the attitude of the author of the article.
t4nkd 10y ago
I tried very hard to take the perspective that this guy is irritated but that there might be some substance to his opinion. I couldn't help but constantly think this, though, "Wow, this guy is really mad, and now wants to logically apply blame to everyone and everything except himself and his choices." Well commented, thanks.
lotyrin 10y ago
What do you propose that people that want to engage in their craft with at least a modicum of craftsmanship do? Even if it truly weren't economical to build quality software and to use real engineering to reduce risks toward achieving that goal (realistic deadlines based on past estimation error, known unknowns in planning, evaluating and training people, scheduling refactors, avoiding defects in the planning stage, planning for the duration of components' lifetimes so you can build things and eventually replace them instead of constant myopic re-architecture) -- which I highly doubt -- who's to say we have to be motivated solely by self-interested short-term economics? If the costs are externalized, of course it's more economical to do everything as shitty as everyone can get away with. What kind of Objectivist nonsense is it to say that that's the same as correct?! For some of us, money isn't motivating, the collective consensus isn't compelling, it's not possible to be simultaneously disengaged and productive, we find investing so much of our conscious time and effort toward something we don't value existentially frustrating and simply want our investment of time and effort to result in software of quality, as simple as trying to maximize for durable utility -- as much as possible, leaving the lives of its users better off for using it, and existing and paying that dividend for as long as possible -- (true economic value) and we find we're not allowed as the majority of managers and team mates have bought into the modern kind of myopic and psychopathic faux economics of me and now. Do you really propose that we are the ones who are wrong? If we are, what's to be done -- do we accept we aren't cut out for the rat race and go live in a van?
- mkozlows 10y ago
  One of the reasons the article is so bad is that it's setting up a pile of false dichotomies, some of which you're embedding into assumptions here. Doing stuff to serve business needs is not intrinsically bad, or opposed to craftsmanship. The whole idea of craftwork is that it serves a purpose, right? It must have an actual function, and the goal is to build a thing that serves that function well. So yes, you should absolutely build software that fulfills its purpose well. Just remember that the business is the purpose, not the software in itself. This isn't just about economics, it's about a larger perspective. Think about the people who use your software, and every time you're thinking about what you're doing, think about how it will impact those users. Will it make their experience better, or will it just make your experience better? (If the latter, don't do it.) Will it make their experience better, but there are other things that they'd really rather have. (Ensure that you're working on the right priorities.) A lot of the things you list as "real engineering" -- realistic deadlines, risk management -- are things that absolutely do help the users: They want to know realistically when they can expect functionality to be there so they can plan for it; they want to know what things might throw that schedule off and be kept up to date on whether they're happening. So a good workplace will use those things. (I'd argue that some of the other items you list are actually not that beneficial, like planning for long-term evolution: The reality is that businesses evolve, and they might get a new big customer, or shift into a new line of business, that will necessitate major rewrites in the application anyway, so trying to plan for that from an engineering side is light folly. But it's mostly harmless, and sometimes helpful; and depending on your environment, maybe it would make sense.) In particular, doing everything as shittily as possible is not beneficial to anyone. Users hate systems that flake out and don't work reliably, right? (At the same time, users might rather have a particular new feature that would save them an hour every day, rather than having you fix that one really thorny bug that's causing the system to need to be rebooted once a month. You'd rather have that, too, if you were them.) So do stuff well, engage closely with your users and customers, think about their needs and goals, and then do the best you can to meet them, while communicating openly and honestly in a collaborative spirit, and committing as a team to high standards. It really does work, in a way that a dedication to cynicism never will.

deleted 10y ago

[deleted]

vosper 10y ago

I couldn't upvote this enough. Also, come on, it's not like everyone doesn't have bullshit in their workplace. I've never heard anyone except software engineers be so self-righteous and pretentious about our supposed special value in the business. Disdain and lack of empathy for working with other human beings comes a close second. Edit, to add: This is by no means universal. I know and have enjoyed working with some very talented, humble, and empathetic engineers, too. I don't think most programmers have the attitude of the author of the article.

t4nkd 10y ago

I tried very hard to take the perspective that this guy is irritated but that there might be some substance to his opinion. I couldn't help but constantly think this, though, "Wow, this guy is really mad, and now wants to logically apply blame to everyone and everything except himself and his choices." Well commented, thanks.

lotyrin 10y ago

What do you propose that people that want to engage in their craft with at least a modicum of craftsmanship do? Even if it truly weren't economical to build quality software and to use real engineering to reduce risks toward achieving that goal (realistic deadlines based on past estimation error, known unknowns in planning, evaluating and training people, scheduling refactors, avoiding defects in the planning stage, planning for the duration of components' lifetimes so you can build things and eventually replace them instead of constant myopic re-architecture) -- which I highly doubt -- who's to say we have to be motivated solely by self-interested short-term economics? If the costs are externalized, of course it's more economical to do everything as shitty as everyone can get away with. What kind of Objectivist nonsense is it to say that that's the same as correct?! For some of us, money isn't motivating, the collective consensus isn't compelling, it's not possible to be simultaneously disengaged and productive, we find investing so much of our conscious time and effort toward something we don't value existentially frustrating and simply want our investment of time and effort to result in software of quality, as simple as trying to maximize for durable utility -- as much as possible, leaving the lives of its users better off for using it, and existing and paying that dividend for as long as possible -- (true economic value) and we find we're not allowed as the majority of managers and team mates have bought into the modern kind of myopic and psychopathic faux economics of me and now. Do you really propose that we are the ones who are wrong? If we are, what's to be done -- do we accept we aren't cut out for the rat race and go live in a van?

mkozlows 10y ago
One of the reasons the article is so bad is that it's setting up a pile of false dichotomies, some of which you're embedding into assumptions here. Doing stuff to serve business needs is not intrinsically bad, or opposed to craftsmanship. The whole idea of craftwork is that it serves a purpose, right? It must have an actual function, and the goal is to build a thing that serves that function well. So yes, you should absolutely build software that fulfills its purpose well. Just remember that the business is the purpose, not the software in itself. This isn't just about economics, it's about a larger perspective. Think about the people who use your software, and every time you're thinking about what you're doing, think about how it will impact those users. Will it make their experience better, or will it just make your experience better? (If the latter, don't do it.) Will it make their experience better, but there are other things that they'd really rather have. (Ensure that you're working on the right priorities.) A lot of the things you list as "real engineering" -- realistic deadlines, risk management -- are things that absolutely do help the users: They want to know realistically when they can expect functionality to be there so they can plan for it; they want to know what things might throw that schedule off and be kept up to date on whether they're happening. So a good workplace will use those things. (I'd argue that some of the other items you list are actually not that beneficial, like planning for long-term evolution: The reality is that businesses evolve, and they might get a new big customer, or shift into a new line of business, that will necessitate major rewrites in the application anyway, so trying to plan for that from an engineering side is light folly. But it's mostly harmless, and sometimes helpful; and depending on your environment, maybe it would make sense.) In particular, doing everything as shittily as possible is not beneficial to anyone. Users hate systems that flake out and don't work reliably, right? (At the same time, users might rather have a particular new feature that would save them an hour every day, rather than having you fix that one really thorny bug that's causing the system to need to be rebooted once a month. You'd rather have that, too, if you were them.) So do stuff well, engage closely with your users and customers, think about their needs and goals, and then do the best you can to meet them, while communicating openly and honestly in a collaborative spirit, and committing as a team to high standards. It really does work, in a way that a dedication to cynicism never will.