> Thus far, I feel my communication skills have been one
> of my strongest assets and strongest attractive features
> for potential employers.
But I thank you for saying that you find my communication style defensive, angry, defiant, and self-important.
I apologize to you for coming across that way. It means I am failing to write my true feelings and I am not living up to the high standard of communication that I set for myself even in a medium like Hacker News comments. It is helpful to hear this criticism from you, even if it's uncomfortable, because it gives me the chance to reflect on what I've written and try to discover how I could communicate it in a way that still expresses my personal values (such as the failure of open-plan offices) but without giving the incorrect impressions of e.g. defiance or self-importance.
Thank you for sharing your thoughts about it with me. I sincerely appreciate it.
> Thank you for sharing your thoughts about it with me. I sincerely appreciate it.
you come across as arrogant and judgmental as well. If a company would rather get things done quickly instead of high-quality, that is their choice. Would you look down on me for driving a 20-year-old car because I want to save money?
We all want to work on interesting jobs all the time, but that's not what work is about. Work is about producing things other people want (otherwise no one will pay you).
In the cases where a company chose to prioritize speed of delivery, it was typically after an overwhelming number of engineers (not just me) had conducted research on the system, the business needs, and so forth, and presented quite a lot of evidence that the fast approach would actually cost the business more money than the more careful approach, even in the short term.
When I speak about prioritizing quality, I am speaking mostly from the point of view of the book Peopleware, especially the chapter called "Quality ... if time permits" in which they offer a lot of evidence to debunk the idea that there must be a trade-off between quality and speed of delivery.
In fact, in the few cases where I've been tasked with pursuing the higher-quality option, I have found that the claims of Peopleware are extremely accurate: people are often more motivated and more productive when they are asked to make something of high quality. As a result, they often actually make something that is both higher quality and delivered sooner than the alternative when they are asked to prioritize pure speed of delivery.
At any rate, I'm attempting to speak from a position where I am talking about adding value in the business's bottom line -- not at all just my personal desire for pet projects or Ivory Tower planning.
I can see how my earlier comments did not include these details and it would be easy to read my earlier comments and to think that I merely wanted to focus on quality for the sake of my own interests.
However, that is certainly not the case.
I'm very glad you pointed this out, because it helped me to see that I need to include more details about the basis of my feelings -- which is a long-running set of research results that illustrate the bottom-line productivity benefits of things like private office space and explicit focus on quality of engineering.
It doesn't matter. You were probably right in your analysis, but it's not your decision. Think of it like a lawyer does: give the best advice, then do whatever the client desires.
I replied to that other comment.
But since you brought up the comparison with a lawyer ... have you ever worked with them? I have worked with lawyers on several occasions and what you describe is not really the sort of thing a lawyer does.
If a lawyer senses that a client is willfully ignoring their advice, and particularly if that client is forcing the lawyer to pursue lines of action that are not beneficial, then the lawyer has many abilities to file to withdraw from representation (depending on the country and the type of field they are practicing in).
I've seen lawyers walk away from clients on a number of occasions, and usually all that is required is for the lawyer to say there is a difficulty agreeing on the necessary steps to best represent the client.
Lawyers have to be aware of this option because if they merely execute the instructions of their client, without lobbying for the client to use the best legal analysis to pick the best course of action, it can be damaging to the lawyer's career. So even if they can keep billing for the hours in which the client just wants to micromanage them, it's often not worth it, because it damages future earnings.
It is very much the same for an engineer. If a boss wants to micromanage (which is essentially the issue you describe -- when a boss ignores or overrides the engineer's critical thinking ability and personal analysis of the best trade-offs and instead demands that some non-optimal action be taken without justification or collaboration), that can be extremely damaging to an engineer's career and future earnings.
Putting up with it in the short term because "that's just how jobs are" and you should "just do it because you get paid for what your boss wants" is a really bad idea, even just in financial terms, because you will be damaging your chances to enhance your skills and your job experience won't cause others to value you highly. And there are other very serious risks too, like the risk of career burnout and prolonged cognitive health issues at work, that are arguably even more serious than financial concerns.
"Give the best advice, then do whatever the client desires" is terrible advice for a lawyer, and equally bad for an engineer (where 'client' is replaced with 'manager').
You were probably right, but it doesn't matter, it's not your decision.
It is the job of an engineer to present the various trade-offs inherent in different options for solving a business problem, including the way those trade-offs affect the business bottom line.
If an employer asks an engineer merely to execute a given decision, and never use critical thinking skill to evaluate the appropriateness of the decision (which is precisely what they are hired as an engineer to do) then it does represent a red flag about that manager, and is usually a strong signal that it would be unhealthy to remain working in that capacity.
In the few times when I have managed others on projects, I've always encouraged them to question my decision making and to reach agreements about our mutual efforts based on evidence, never on authority. I admit it's only a limited set of projects that I oversaw this way, but it always produced good results and the people working with me said they felt it was a positive way to be managed.