6 ms·
Stop hunting programmers. Many of us actually don't care about the deadlines, the users etc. We just love to program. We don't care about stand-ups, story point
by wildcow 4y ago
Stop hunting programmers. Many of us actually don't care about the deadlines, the users etc. We just love to program. We don't care about stand-ups, story points or whatever the business uses to convert complexity to billable hours.
http://programming-motherfucker.com/ http://programming-motherfucker.com/
- deleted 4y ago[deleted]
- meindnoch 4y agoFinally, a movement I can identify with!
- tjpnz 4y agoNot only will I be buying that t-shirt, but I'll also be wearing it the next time I get asked to interview someone. That'll teach them.
- cube2222 4y agoThere's a difference between programming, the hobby, and programming, the job. In one of these you're paid to care.
- vaylian 4y agoTrue. But it would help some managers to understand that there is more to programming than just achieving business goals.
- throwaway98797 4y agothe only other goal a manager should care about is if the programmer feels fulfilled i bet a lot managers know that devs don’t care about business goals
- eastbound 4y agoAs 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.
- M5x7wI3CmbEem10 4y agothank you for sharing. how did you learn to become an effective owner? any book or blog recommendations?
- eastbound 4y agoHN. 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.
- mgkimsal 4y agoPerhaps 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.
- pcthrowaway 4y agoAlso 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
- fallingknife 4y agoSorry, 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?
- jmclnx 4y agoWell here is the thing. 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.
- sirsinsalot 4y agoI'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.
- jmclnx 4y agoActually 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 :)
- mattip 4y ago> You see this with Opensource too 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.
- sensanaty 4y agoMore like paid to pretend to care :)
- ThatOneUnityGuy 4y agoWow, seems like this guy really knows something. Hey look, he even sells "learn it the hard way" books for $29.99!
- tester457 4y agoUnironically his free books are okay
- Night_Thastus 4y agoWell, I sort of disagree with part of this. There is a line between useless complexity and useful complexity. Code review, having a clear software development lifecycle (not rigid, just clear), testing, good and frequent communication between developers and from developers to the higher levels, and spending more time on design are not bad things. They can save a lot of time and frustration in the long run.
- sakisv 4y agoAssuming it's not a joke site, I could kinda agree with some of the "values" but not with the "pointless tests". I mean, I agree that some tests are, indeed, pointless, but I wouldn't trust someone who "just wants to program" to decide which tests are useful and which are pointless.
- BillyTheKing 4y agoThose comments against pair-programming, or testing, or PR reviews etc. just make me wonder about the industry the author is in. I used to think similarly, but after working in and on Fintechs for a while I just totally disagree. Small bugs can have crazy costs - there's literally a price-tag on those. So minimising bugs in production makes a lot of sense both for the company as well as the developer's mental well-being. I assume it's similar for programmers in the health-care, or aviation, etc. industry. It probably matters a little less for programmers in the ad-tech industry, in which case it's fine to be more risk-taking in your programming. Programming != Programming, different approaches make sense for different products and industries.
- sirsinsalot 4y agoAs both a programmer and manager of teams of programmers, this take is wrong. Don't use "we" when you mean "I". If I interviewed a programmer who had this view point, they wouldn't get the job. Good (not necessary) processes manage risk. Risk needs to be managed whenever money changes hands in exchange for goods and services. These processes ensure you get paid. It's a profession. Just as a builder or architect shouldn't hate plans and drawings, programmers need to care as much about the surrounding engineering processes as the "hammer and nails" act of coding. It's the difference between a professional engineer and an arrogant, hobby hacker.
- H8crilA 4y agoYou are absolutely right. But I will fake my way into your company on the whole business thing and still remain an arrogant, hobby hacker. But not too arrogant. You simply need my technical skills and I need the $$. Plus the job is often fun, at least a good portion of it. At least for a while. I am really happy there exist more business people that look after processes and whatnot, because it does seem like we (society) need it, to some degree.
- tylerrobinson 4y agoThis is such a wild take and would be so toxic to any organization. Assuming you’re not trolling: you might be surprised to know that your colleagues are actually not, in fact, idiots, and will sniff this out. For how many years do you suppose you will find it rewarding to fake your way from one thing to another? 5, 10, 20, your whole career?
- Footkerchief 4y agoFrom an anecdata standpoint, I would say this describes the mentality of ~20% of my past colleagues, and it didn't particularly correlate with their productivity. Inversely, the not-faking-it true believers bring their own problems, like failing to recognize (and hedge against) the possibility that their managers are incompetent and untrustworthy. From an ethical standpoint, this is no more toxic or false than the facades presented by many employers to their employees.
- pcthrowaway 4y agoI can't fathom how a software dev could not "care about users". Like, what, are you building software in an ivory tower for yourself? It's such a self-centered attitude. What do you care about other than 'tinkering'? Surely you have to care about at least delivering the bare minimum of results, or you wouldn't be valuable on a team.
- moffkalast 4y agoHave you met users? All they do is break stuff and complain, injecting complexity because of their varying platforms that need to be supported and features they thought would be neat. Writing code for yourself is the best.
- spritefs 4y ago> I can't fathom how a software dev could not "care about users". In a large company, there are so many layers of abstraction between you and the users that it's difficult to see how something could benefit them. Also on top of this, I don't think that showing users more ads is supposed to "benefit" them. There are so many orgs like this, where you hear this claptrap about "benefiting the user" when it's really just showing them more ads or something like that At this point, what else is there to care about other than just writing good code and making sure it's correct?
- janee 4y agoI think the fact you mention billable hours is telling. What about caring about problems and their solutions? Because that's the core driver for me. I often feel other programmers fall into this trap of technology usage for the sake of technology usage and less about solving real problems. I think having a distaste for process is justified when working in environments where there's no buy in from the team...but don't assume that applies to "many of us"