At work all we hear about is "put the customer (user) first" which is great. But in reality you get 'dinged' if you really do that. In the 80s and very early 90s, I would work directly with the user to give them what they want. The users would see real progress so was kept happy, no matter how long it took. You just had to prove to them why you are having issues. Not a big deal.
Then the methodologies came in, far more than I can remember. Now, god forbid I forget to keep Jira updated. Also, I have not talked to a real user in many years. The outcome, the real users are frustrated because they get their statuses from their managers who attend meetings that show meaningless 'high-level' presentations.
The web site should add a line for "high-level", meaning "I am too dumb to look at details, here is a pretty picture". When I hear "high-level", I know the meeting will contain no real information.
You can see this with Opensource too, in the Early Days of Linux, if a user had a problem, Linus or someone close to him, would respond directly and it would get fix rather quickly. Now companies run the show, so we get things we really do not want. But to be fair, I think Linus still tries to cut through the bureaucracy when he can, with little success.
The most enjoyable programming jobs that I had were ones where I was also a 'user' of the software and was given power to build features that I personally wanted. I think this is common in open source projects that are started by people who couldn't find software that did what they wanted, so they wrote their own.
Businesses are there to make money and pay the bills (including the salary of the programmers) but the needs of the users can get lost sometimes in the shuffle. Managers are so busy trying to meet some goal set in a 'high-level' meeting that they lose focus on what would make customers happy.
My current project is very enjoyable. I built a system that I personally wanted (data management) and worked on features that I thought were important. I work closely with customers and beta sites to figure out which feature should get my attention next. It's not finished until I am personally happy with how it works.
I'm sorry you've had bad experience of being managed.
That isn't the case for everyone, and not a reason for "black and white" thinking where you take the extreme position of rejecting the tools used badly against you ... rather than placing the individuals accountable.
It isn't the tool's fault, be that meetings, agile, estimation, jira or anything else.
Actually my direct managers are very good, the only reason I am staying, this is a very large company and rules are imposed upon us from senior VPs (direct reports to the CEO). One example, points from all Devl groups need to be combined and rolled up to the VP, and we need to increase 'points' by a small percentage every iteration.
Last I heard, the squad decides what points mean so how can that be rolled up :)
I think it depends what project you want to interact with. In the projects I am involved in (Python, Numpy, SciPy, Cython, PyPy) you will get a response from a core dev quite quickly.
As a founder, I pay programmers who care about customers about 50% more. I’ve actually doubled the salary if a total junior within 10 months of hiring, because he cared about business goals.
I also work to eject those who can’t work with customers. We’re not here to serve the beauty of JUnit tests. I simply don’t understand the “programmers aren’t paid enough” torpe; It’s only true for purists who don’t dedicate their work to building a business.
Perhaps overly semantic, but... there's a conflation of "care about customers" and "cared about business goals" there. Ideally, they're the same thing, but not always. And if you care about customers, but are 'managed' in to doing things which are clearly at odds with what the customers are wanting... you're in a bind.
Also a conflation of customers and the users (mentioned upthread).
The business's goal is generally to extract as much value as possible from its ability to balance servicing customers and users, and managing operations. I've never worked anywhere where there isn't a fair bit of conflict of interests between those three groups
HN. Really, that was back at the time of PG essays and Kalzumeus’ 10,000-words blogposts. But I’m probably not an effective manager, I was just a good founder, a passionate creator, and luck/market fit struck me.
Sorry, but as a professional programmer, the entire point of your existence is to achieve business goals. Why would a business pay you to do anything else?
At work all we hear about is "put the customer (user) first" which is great. But in reality you get 'dinged' if you really do that. In the 80s and very early 90s, I would work directly with the user to give them what they want. The users would see real progress so was kept happy, no matter how long it took. You just had to prove to them why you are having issues. Not a big deal.
Then the methodologies came in, far more than I can remember. Now, god forbid I forget to keep Jira updated. Also, I have not talked to a real user in many years. The outcome, the real users are frustrated because they get their statuses from their managers who attend meetings that show meaningless 'high-level' presentations.
The web site should add a line for "high-level", meaning "I am too dumb to look at details, here is a pretty picture". When I hear "high-level", I know the meeting will contain no real information.
You can see this with Opensource too, in the Early Days of Linux, if a user had a problem, Linus or someone close to him, would respond directly and it would get fix rather quickly. Now companies run the show, so we get things we really do not want. But to be fair, I think Linus still tries to cut through the bureaucracy when he can, with little success.