10 ms·

> the actual work of being a developer/programmer in a professional setting is a really shitty job and sad life The thing is, it doesn't have to be and, until

• randrews 7y ago
  I would add code reviews to that. The advent of those was when it really stopped being fun for me, because it's really hard to keep that from turning into "your boss nitpicking every line you write."
  • oriolid 7y ago
    In my opinion this is much, much better than trying to decipher what the heck that one co-worker pushed to production and how exactly it broke things. Of course there are ways to smuggle rubbish through code review, but it's still better than no reviews.
    • randrews 7y ago
      Both have problems. The best system is one where a passing review means "I feel comfortable maintaining this;" too often a passing review means "this is how I would have written it."
      • Silhouette 7y ago
        IMHO, review processes should concentrate on identifying problems, not solutions.
      • wes-k 7y ago
        Agreed. Few things to consider: - linters to help move away from code style comments - Peer code reviews (if possible) - inform your team/boss of bike shedding - use a tool like reviewable.io where comments can be marked as blocking or not. I’ll often comment on preferences and block on issues.
        • randrews 7y ago
          Yep. I've worked on great teams that did all those things. And not-so-great teams that didn't. The latter is really draining.
      • Stratoscope 7y ago
        I have suffered under far too many "this is how I would have written it" reviews. It can be really demoralizing to write perfectly good, working, readable, performant, well-tested code only to have it rejected and have to rewrite it because the reviewer wishes you had used a different C++ feature. I tried something like your "I feel comfortable maintaining this" approach recently when I was the reviewer. We have an internal geodata visualization tool that I've done some work on lately, and a talented C++ developer added a cool and useful new feature to the JavaScript front end. He asked me to review it and said, "I'm sure you will find a lot of things I should change! This is my first real JavaScript project other than some hobby stuff." And he was right. There was a lot of stuff I would have done differently. There was a mix of jQuery and document.getElementById, a fair amount of repeated code, var instead of const or let, and so on. Our "house style" for reviews would have been for me to comment on every single one of these things line by line and expect him to change them all to my satisfaction. It would then require a second review pass to clear up misunderstandings, and a third to see if it all ended up OK. Instead I told him: "Your new feature is awesome! You're right, there are a lot of nitpicky things I would change in the code to bring it up to more modern JS style, and I'm glad you asked about that. But I didn't find anything that looks broken or dangerous. And the feature works, right? I could spend half a day writing comments explaining everything I would do differently, and that would keep you busy for another half day fixing it up. But I know you have more important things to work on right now, so maybe we can try something different. Go ahead and submit the code as is so people can start using it. When I get a little time I will just go ahead and make the changes I'm thinking of. I'll add review comments on my own changes and send it to you for review so you can see what I changed and why. That will avoid a lot of back-and-forth. I think it will save us both a lot of time and be a more pleasant experience too." Needless to say, the developer liked this idea. And his manager was within earshot when we discussed it and thanked me for thinking of this approach. I still haven't made that update, and this reminds me to do it sometime soon. But the code still works, people are using it productively, it has not failed once, and who really cares if there are some minor imperfections in the code style? None of our code is perfect!
        • blub 7y ago
          You'll never do that update right? The more you wait, the more that developer will get annoyed when you interrupt them with it. :) In this case actually I would have taken the half an hour and sat with them to explain what I think should be done differently and why, prioritized by importance. Reviews done through tools work if there aren't many comments and if the basic design is ok. I've seen reviews where someone's not skilled enough and they have to be taught idioms in dozens of comments in 10-20 patch sets. It's pretty horrible, but the positive side is that at least they're not merging crap.
  • blub 7y ago
    Code review is one of those things where the culture around reviewing and the experience of the reviewers makes all the difference. A code review where the boss reviews code is pathological. When experienced peers do the review it can be brilliant. In fact I would only trust a team of very competent seniors not to need code review. Even then, getting another opinion on your code can be worth it.
    • atq2119 7y ago
      Everybody needs code review. Though the way I scan the code during review does change by how much I know and respect the author on a technical level. That correlates with but is not identical to their formal seniority.
  • ambicapter 7y ago
    I don't think are any good work techniques when you're surrounded by assholes.
• wpietri 7y ago
  For me daily stand-ups are a great tool for closely collaborating with colleagues. I get that managers have often turned them into top-down status report meetings. (And that almost anything "Agile" has similarly, despite initial aims, been turned into an instrument of control.) But my best working environments have been in strong teams, and I'd hate to see the baby get thrown out with the bathwater.
• pmiller2 7y ago
  I don't have a problem with standups. I actually like having ticket tracking systems (how else are you supposed to know what is high priority to work on?). But, open offices are objectively terrible. Research shows it, people here complain about it all the time, and yet companies keep building them. Where I'm at, the floor is divided in such a way that teams sitting together can sometimes have their own little "bull pen" area that's a little bit separated from other teams (if only by a whiteboard wall). This helps, and I like working in an area with just my team, but I would prefer real walls.
  • celticmusic 7y ago
    I hate standups with a fucking passion. All a standup to me is an interruption 30-45 minutes into the day which causes me to lose an hour or more of time every single day. I basically just fart around with things that don't need much focus until the standup happens. The worst part is that I suggested instead of standups we just send what we we would have said in the standup via slack. That lasted 3 days. The reason no one liked it? "I don't read what other people put into slack". Yeah, ex-fucking-actly. It's literally not helpful because you don't actually need to know what someone is working on that day, and if you do it's because you're also working on it and you can communicate that privately.
    • szatkus 7y ago
      If it takes 30-45 minutes something is wrong. I hated standups as well until I worked with right people.
      • celticmusic 7y ago
        you misunderstood, the standup happens 30-45 minutes into the workday.
        • pmiller2 7y ago
          Show up 5 minutes before standup, or 5 minutes into it, then. Problem solved. ;) On a more serious note, read email, get a drink, and plan your day. You’ll be talking about the plan in less than an hour, anyway.
• Silhouette 7y ago
  The thing is, it doesn't have to be and, until relatively recently, honestly wasn't. Indeed. It's almost as if it's a bad idea to take people working in a field where creativity and careful thought are fundamental and a wide variety of experience with different but related ideas is often helpful and then try to turn them into interchangeable commodities with the whole process dumbed down to the level of the least competent developer or manager in the team. For my own career, escaping that sort of foolishness was the single biggest benefit when I made the jump to freelance work and even more so when I first became a founder. As soon as you go independent, you're no longer dealing with a subordinate employer-employee relationship, where everything you do is subject to the whimsy and caprice of whoever pays your salary. Instead, you're dealing with a business to business client-service relationship, where your objective is to provide the service the client needs. How you choose to solve whatever problem they have in terms of technology or process is much more down to your own professional judgement. If you do follow entrepreneurial route, you become effectively both client and service provider in that sense, and it's what you learn from your market research and customer relations that guides your direction in often even more general terms. There was a time when programming was exciting and rewarding. IMHO, it still is, as long as you find an environment where using fun things to get useful results is the emphasis. Mind-numbing corporate box-ticking is soul-destroying in any field. We're privileged to work in a field where all we really need to do useful work is often a laptop, an Internet connection, and a willingness to use our brains, and where that work can still be valuable enough to others to make a very nice living off it, and where there is no shortage of potential customers. Now, there's nothing wrong with being a competent professional who turns up and writes software during office hours and then goes home to enjoy life with their family/friends/hobbies like anyone else, and maybe for those people the structured corporate environment is helpful. And of course going independent has other challenges that aren't just about technical skills, and those are not for everyone. But for anyone who wants more than an office job and doesn't mind taking on a broader skill set to operate independently, I don't understand why they would continue to work in the kind of toxic employment environment we are discussing today. I suspect that in many cases it is simply ignorance (meant literally, not derogatively) of the possible alternatives and the paths to transition to them. Incidentally, as a convenient side effect of working as an independent professional or through your own hopefully more enlightened business, the sort of ageist nonsense that motivated today's discussion also largely disappears. For a lot of clients outside the tech bubble, a 25-year-old in trendy clothes spouting the latest buzzwords is much less impressive than a 45-year-old who immediately gives off a competent, professional vibe. And if you're the 45-year-old who did keep up with developments and has had an extra 20 years of honing their skills, your rates can reflect your greater capability and productivity, which is much harder to achieve if you're still someone's employee at that point.
• antisemiotic 7y ago
  >open offices Noise-cancelling headphones are mankind's greatest weapon in the hopeless war against braindead management practices.
  • PedroBatista 7y ago
    Do you guys now understand why I've said it's a sad life? We are so "important" to mankind, yet the best we can do is to buy Noise-cancelling headphones.
    • cgh 7y ago
      Fair point, but to be honest nearly all modern work is borderline dystopic, regardless of how "important" it's deemed by society. If you think being a programmer in BigOrg, Inc. sucks, then take a summer and work on a construction site or with a landscaping crew. Trust me, you'll yearn for that loud, open-plan office soon enough. Modern society would quickly implode without plumbers, yet actually being a plumber and crawling around under houses in rat shit is not very fun.
  • jackstraw14 7y ago
    This doesn't work for me. It seems depressing as hell that we have to put in earplugs and pipe distracting media into our brains just to make work tolerable. How is cutting off one of our senses from our environment a solution?
  • CalRobert 7y ago
    Surely evidence of the declining mind share of unions.
• rolltiide 7y ago
  As long as we exempt engineering teams from OKRs I can tolerate it
• p0nce 7y ago
  None of this is true if you work for yourself.