1. 38
  1.  

  2. 21

    It was so isolating that you didn’t talk to anyone for the entire day. The only interaction were occasional emails where you had to fight a difference of opinion and your weekly reminder to submit your timesheet. The only time I opened my mouth, was for the 30 second status update in the standup.

    Interesting experience. Exactly the opposite for me. The more senior, the more meetings. Now I’m barely doing any programming anymore, I’m just talking to programmers and I worry that my skills deteriorate.

    1. 5

      I woke up in a cold sweat earlier this week - I dreamed I was going to be fired because all I seem to do is talk to people, and I spend more time in Excel and PowerPoint than Emacs.

      1. 3

        Worse. You might get promoted and do even more of it.

        1. 3

          I still take some comfort in knowing I get placed on the yearly fire. Every year something important slips the planning schedule, or something horrifyingly essential breaks, and me and the other Powerpoint-slingers suddenly start writing code again.

        2. 2

          I have had the same experience working at a company, though as a junior. 6 people in an office and only the sound of keyboards keys clicking. One colleague with a triple-spacebar-bashing tic…

        3. 12

          This is a really great article because for a change the author isn’t saying “The industry is terrible. Goodbye” they’re saying “I had a terrible experience, I’m not enjoying this anymore, and I made the change that was right for me.”

          Super refreshing.

          1. 7

            It was the culture surrounding the whole thing that really bothered me. I felt like a pawn in a sweatshop. I was given JIRA after JIRA ticket with no choice but to do what it said. Few companies let me have a say on what the task should be like no matter my seniority level.

            I feel this too. For me it’s dramatically worse or better at different places (like the author I’m a contractor so move around more than usual) but very depressing anywhere it happens.

            I dislike it professionally because places that are hot on this kind of (pretend agile) micromanagement tend also to be the places with serious technical problems that no one is addressing because they’re all too busy doing stuff that’s in their JIRA backlog.

            1. 3

              I was given JIRA after JIRA ticket with no choice but to do what it said. Few companies let me have a say on what the task should be like no matter my seniority level.

              Isn’t this what you sign up for as a contractor? I’ve always assumed that high contractor salaries is partly to compensate for the dullness of the work. Moreover, in my experience contractors are typically not on call. It makes sense for permanent (i.e. in it for the long haul) staff to design and build systems, as they’ll be around to support and maintain it.

              That said, I’ve never been a contractor myself. I’ve worked with some though, and have friends who are. I have only anecdata, but I am fairly sure that my contracting friends complain more about deeply dysfunctional workplaces than my friends in permanent positions. Maybe because dysfunctional companies are more likely to hire contractors?

              1. 4

                Partly the higher compensation as a contractor is due to higher risk. When I was contracting, I would say, “we come pre-fired.” Part of the gig is that you are the first to get cut because the company is using you purely as flexible labor. Another part of the gig, maybe more on the upside, is that the dull parts are easier to stomach when you know it is finite. When people get twisted its usually because they feel trapped. (Can’t afford to leave, can’t stand to stay, can’t get hired someplace else without skilling up, can’t skill up because too enervated.)

                I’ll say there’s also a world of difference between being a contractor versus a consultant. Consultants still come pre-fired. But as a consultant, my goal was always to work myself out of a gig by getting my clients to be self-sufficient. Between contractor and consultant, I’d always take consultant.

                1. 1

                  I’ve always assumed that high contractor salaries is partly to compensate for the dullness of the work.

                  I’ve heard this point of view before but it has never rung true to me. Your contractor is invariably working with all the other staff on the same things that they are. In the “JIRA factory” case: you’re working on the same tickets. I’ve never had a client reserve some especially dull pool of tickets for me or heard of that happening to another contractor.

                  One other factor in this is that, in my locale, contractors tend to relatively senior technical staff. I don’t want to over-egg it too much but for many the alternative to being a contractor (and staying technical) is often going into management (and becoming less technical).

                  Moreover, in my experience contractors are typically not on call. It makes sense for permanent (i.e. in it for the long haul) staff to design and build systems, as they’ll be around to support and maintain it.

                  Employees leave just as well as contractors - the difference of course is (again, in my locale) you cannot lawfully ask an employee to leave. I tend to do a fair amount of design though the best predictor of that is whether the other staff are doing any design. If there’s some architect character around then typically no one is doing any design. Often that turns out badly.

                  Maybe because dysfunctional companies are more likely to hire contractors?

                  That depends greatly on the nature of the dysfunction but where the dysfunction is impairing hiring they certainly do turn to the contract market eventually. They are not the only ones to do so: the biggest source of contracts is organisations who have a big programme of work on, particularly if it will eventually conclude and they will want you to go away at that point.

                2. 2

                  That’s a problem that’s really chipping away at me in my current job, the idea that the JIRA board is the end all productivity solution and clearing it is the only way to do things. An incremental rewrite that I had proposed for after our SDK’s 1.0 release was unceremoniously shoved into a 3 day period simply because it fit into a hole in the JIRA board. I am proud of what the company’s trying to do and my role in it but this agile workflow is so broken and draining that I’ve already started looking for jobs elsewhere.

                  1. 2

                    “Pretend agile” strikes a chord. I have this belief (unsubstantiated by data but rich in experience) that the places which are most like JIRA ticket factories are the ones who’ve never figured out that agile methods don’t work when you don’t change the front end of the process. By that I mean, if your company’s product development approach is still waterfall, then dev will be a ticket factory no matter what, because there’s no meaningful product design happening there. It all happened in the BRD or HLD or TAD or whatever the big batch document was that someone (a pretend product owner, most likely) carved the document up into stories that “just need to get done.”

                    1. 3

                      For me it feels like the majority of “agile” that is occurring is cargo cult. Like in the original Feynman example the poor victims of the cargo cult have latched on to the tangible elements of agile (“kanban” boards, small work items, certain meetings and ceremonies, etc..) but still the planes don’t land!

                      1. 2

                        Indeed. I’ve got colleagues who unironically refer to “the Scrum ceremonies”. When I learned lightweight methods (before the rebranding to “agile”) we used “ceremony” to mean an empty ritual that should be eliminated. It feels like the ceremonies are all that is left in many places.

                  2. 6

                    There’s a weird paradox where you get lots of leeway to design new things early on in your career, but as you get more senior, your employer makes very sure your expensive hours are directed at grinding bugs on the business critical legacy system - that was probably designed by an intern two decades ago.

                    And even if you’re willing to take the pay cut, you can’t go back to being treated like a junior.

                    Even twenty years ago, I was warned that programming was a very limited career path, both professionally and financially. If I still had the same freedom I had as an intern / junior, I wouldn’t mind it at all.

                    1. 6

                      I would describe it differently: The intern gets to work on something non-critical if not optional, so they can design whatever they want. The expert works on the important stuff. While made by an intern, it evolved and accumulated a lot of constraints over time. The expert has to follow these constraints.

                      What you should keep in mind is that lots of stuff interns build is thrown away after a while. Mind the surviver bias.

                      1. 1

                        Definitely, just like a painter throws out most of his paintings. That’s part of why they have such creative freedom. The software I wrote as an intern ran (and made money) for several years, but I’m pretty positive it was retired after that. To me, that matters a lot less than the fact that it was satisfying to design and write.

                        I’m sure that some people derive a lot of job satisfaction from the idea they’re working on something important. But I don’t think that’s true for most of us.

                        1. 3

                          Yes and “important” usually translates into “makes money for the company”. Not necessarily a worthy personal purpose. It might work if your company “organizes the world’s information” or “connects people”. It does not if your company exists to sell personalized ads.

                          1. 8

                            It might work if your company “organizes the world’s information” or “connects people”. It does not if your company exists to sell personalized ads

                            That’s ironic, considering those first two are the missions of Google and Facebook, respectively. And the latter sounds like both :)

                      2. 1

                        What does “very limited” mean? I’m just genuinely curious! What are not limited career paths?

                        1. 4

                          The way it was explained to me back then was that the salary and working conditions are very good initially, but the typical programmer reaches the upper limits of his earning / impact potential by the time they’re 35 - after which there may be other opportunities, but they don’t involve programming. Financially, this is also the age when people in other (similarly educated) professions overtake you.

                          Having passed that age, there seems to be some truth to that. Talking to people in other fields, 35 is only the beginning for a lawyer, for example, whose time is presumed to get more valuable as their experience increases. In many fields, autonomy seems to increase further the older you get, whereas in software development, autonomy seems to decrease.

                          I’m sure software development isn’t unique in that sense. And I still prefer programming to most other professions I can think of. But it has lost the playfulness that made it so intensely satisfying when I was younger.

                      3. 4

                        Agency comes from investing in skillsets that don’t have a large supply of competing laborers, and ideally several because every skill has an expiration date. Investing means saying “no” to things that are not along this path. It can feel scary to say no, but this is a cognitive bias that keeps most people on the low paying, low autonomy, easily replaceable paths who are often building things that commoditize the niches where individuals may have previously prospered. Capitalism is brutal and if you ignore it, you will be chewed out. Due to our proximity to capital flows, we have significantly easier options for capturing nice working conditions than any of the jobs the op mentioned as alternatives. I choose not to be a 1%‘er but I trade that for significant free time, and I’ve been able to take several multi-year breaks from work before 32. We can carve out so many ways of life, we are extremely privileged despite declining real wages and an essentially cannibalistic army of coders seeking to out-automate your current job. I’m not expecting this freedom to last so I’m taking advantage of it to the fullest extent I can.

                        1. 5

                          every skill has an expiration date

                          Programming skills, maybe. Understanding the boring, banal parts of industry is where it’s at.

                          Learn how freight works (getting a package from A to B is stunningly complex), or how geological surveys are performed (funding, site selection, the whole shebang), or pricing strategies for B2C.

                          1. 1

                            “durability” is the metric I scream about to anyone I’m mentoring. Key factors for that are how foundational the thing is, rather than topical aspects that will probably go out of vogue in 1 year. The deeper it is in the overall mechanical stack of widely depended on tech, the slower it will be to move due to the weight of everything on top of it. Learning how TCP-related syscalls map to things eventually ending up on other machines has been one of these, similar to freight in some ways. I think freight is a great example because a huge chunk of the world depends on the fact that it doesn’t change very much.

                            Human skills, legal and tax environments, and generally anything that structurally exists in a form that requires change to be infrequent due to dependency.

                        2. 2

                          Like others in this thread have pointed out, I appreciate that this post is mostly saying “I didn’t have a good experience and so I’m out.” More people should make changes like this when they aren’t happy.

                          That being said, it feels like all of this isn’t the fault of software engineering, but a failure of project management.

                          I can’t overstate how much project management influences the output, morale, and culture of a company. I’ve recently been trying the Shape Up methodology with some clients of mine and it’s been a really nice breakaway from “agile” and “sprints” as a whole. I always disliked agile but for reasons I couldn’t fully or accurately articulate until recently.

                          My biggest complaint about it is that I always felt like 2 weeks wasn’t enough to really do anything meaningful, and that huge projects would get lumped into that time slot just because it was the default for agile, and then expectations were set. It sets developers up for failure, and it approaches software from the wrong angle: time-based instead of scope-based assignments. This is where the classic paradox of “I can build this in a weekend at a hackathon!” vs “It will take 2 weeks to create this button on this form.” really originates.

                          Overall, I hope the author finds a career that’s better for them an that, as an industry, we’re able to figure out how to better handle project management. It is by far the largest source of grief in my career.

                          1. 1

                            Honestly, I’ve always enjoyed other jobs that aren’t related to software including doing ten hour-shifts as an Uber driver despite it being really tiring.

                            I’ve had a discussion with a Uber driver in Paris who had a similar background. He was also a former software consultant and felt happy enough as a driver, even with a significantly lower income. This still makes me think a lot.