4 ms·

Early on in my engineering career, there are a handful of times I was assigned to a project where I was set up to fail. I didn't understand the situation until

• nomel 3y ago
  As a senior person, these are some of my favorite types of projects, because I feel like it's where I'm the most useful, and where I can have the most impact: understand the need, then implement the need rather than the request. When I see people struggling with these, it's usually from a lack of information seeking/gathering, where they first sit down and code rather than spend the first few weeks talking, reviewing understanding, and, most importantly, finding those few A-team people that have meaningful input. Definitely not something someone early in their career should be given, but these types of problems usually benefit from devaluing manager input, since they have a disconnected/warped perception of reality. I take these projects only if the understanding is that I'll be solving a problem, taking input from all involved, rather than implementing a specific solution.
  • j45 3y ago
    Getting the need right, in lockstep with the audiences realization of it is an important soft and hard skill that should be better taught.
    • nomel 3y ago
      > in lockstep with the audiences realization Perfect wording! I tell people the hardest problem, in my work, is getting people to see there is a problem. The crazy workarounds that people will come up with, to avoid the root issue, are really incredible.
  • softfalcon 3y ago
    Yeah, these types of projects can turn out to be a real gift. They are essentially a "folks here have an initiative they want to fund but don't know how" and if you direct the conversations well, you can create something incredible out of it. Things being up in the air and vague is often an opportunity to step in a tame a wild forest of ideas into a real application. It definitely takes a certain type of mindset to harness that energy and herd the cats though.
  • pdonis 3y ago
    > I take these projects only if the understanding is that I'll be solving a problem, taking input from all involved, rather than implementing a specific solution. If this is the case, I would say you're not being "set up to fail", which was the explicit description the GP gave. "Set up to fail", to me, implies that whoever is tasking you is not tasking you to actually solve the problem, either because they're too clueless to know that what they're specifically tasking you to do won't work, or because there is some other hidden agenda in play.
  • gryn 3y ago
    that's assuming you have somewhat cooperative people, in which case I don't think it's a setup to fail situation. my reading of it was more like some past experience where I tried to do what you described only to be reprimanded for "overstepping boundaries" and that not being my job function, especially when the manager/PO/etc insist on being an exclusive gateway to information despite repeatedly failing to do that job correctly. I think we all agree on the importance on your last part where you need to suss out whether they want an obedient code monkey or someone to solve the problem. probably through an iterative dialog where the parties involved get to explore and update their understanding of the problem, the technical and non technical constraints and the solution space.
    • robocat 3y ago
      > especially when the manager/PO/etc insist on being an exclusive gateway to information A strong signal to leave a sinking ship. I suspect even if you somehow pull a rabbit out of the bag you wouldn't be rewarded for it. I stuck with one project like that when I shouldn't: I finished the work however the useless salesperson was screwing up the communications with the client and didn't get the project across the line to them. One of the most demotivating environments to suffer.
      • whstl 3y ago
        This 100%. This siloing is what causes fear and uncertainty about project, and also what makes developers atrophy their "talk to users" muscle. It is what made me leave jobs in the past and made me fight to change how things work at my current job.
  • pjerem 3y ago
    I agree with you but there are two prerequisites for this to work : - as you said, this can’t be too soon in your career : gathering requirements and knowledge is something that you can’t do without experience - you need to be 100% confident that you are working in an environment where you will be rewarded accordingly. Working hard on those projects just to see your manager be promoted will be an absolute emotional disaster. If one of those requirements aren’t met, you are good for burning out.
    • whstl 3y ago
      I agree, and I also find that it's mostly developers with experience that are able to do it... but it's not because of seniority: it's because people with 10+ years of experience simply had to learn it in the past. In the past there was no choice: developers would talk to users and stakeholders and collect information. Today there are few opportunities for a junior developer to do this.
      • lozenge 3y ago
        That is experience! There is a saying - some people have 10 years of experience, some people have 1 year of experience 10 times.
      • helboi4 3y ago
        That would be really cool to do. One of the reasons I became a dev is cos I used to work for customer service in a games company and I was frustrated with the fact that there were ongoing bugs that I could've fixed if I was in the dev position. In reality, as a dev I am now on the other end where we never really hear feedback from users and there always seems to be some agile race to the bottom where we try to fix as little as possible as simply as possible.
        • whstl 3y ago
          I had several instances of product people asking stakeholders, users and support people not to talk with developers. Prioritisation had to go exclusively trough them. There was constant complaining from both sides: from product that "tickets opened to us are horrible, support/customers are ignorant" and from customers that "nothing ever gets done here". In the end nothing of that was true. Nobody was ignorant and a lot was getting done.
• ElevenLathe 3y ago
  I've rarely had a task assigned to me that was well-defined enough to even know if I completed it. Usually there is good intentions, but the people above you just don't have time to dig into the details of what it is they think they are assigning to you. This also means that they can't really check up on you too well, either. The trick is to just dig in, do some research, do stuff (ideally stuff that genuinely needs doing, that you can accomplish, and is related to the "task" you have been given), and report on it confidently. Eventually people will consider you an expert on that issue/area and will defer to you about what needs to be done. Once you hit this point, you can make a list of "nice to haves" in this area, throw them on the backlog, and declare yourself done. If you're recognized as the main expert on that subject, it will be tough for people to argue with you.
  • tibbar 3y ago
    I think the difference here is that a 'bad' project will often be very specific. You will have a very particular outcome that you must achieve to finish, and you know what it is. ("Migrate our database from NoSQL to a relational database!" etc.) But you don't actually have the skills to perform the task, or the support to even get started in the right direction. You don't even know what questions to ask, or who to ask them to. You're just ... lost. It's also possible the project is simply too hard -- maybe doing it right would take an experienced engineer two years; but since that approach seems like obviously too much work, you flail around assuming there must be some alternative. This is, sadly, pretty common for junior programmers and people who are new to a team.
• nestorD 3y ago
  > Early on in my engineering career, there are a handful of times I was assigned to a project where I was set up to fail. I didn't understand the situation until far too late. There are a few tell-tale symptoms: I didn't quite understand what I was supposed to do; I didn't really know how to do it; and I didn't understand how the assigned work actually solved a higher-level problem. No one else did, either (these situations usually represent a failure of management.) Yes! I have been in such a situation once (I didn't quite understand what I was supposed to do and no one else did, either) and, to this day, I remember it as a cautionary tale when I think of moving to a new position. The people who think that they can shine in this situation by being proactive underestimate the lack of understanding: it is not a blurry task, it is a task where you are told to do X and no one knows what X actually means. You can do great things, but they will not be able to deliver on the requirements.
  • XorNot 3y ago
    Reminds me of when I was hired as an SRE, then told you can't log on to any of the customer systems until you've committed code to the main infrastructure codebase and you're "trusted". This was the only thing the other members of the SRE team actually did though - the job itself was basically "figure out why things go weird sometimes in the customer systems and then fix underlying automation issues". But there was an actual developer team as well, including all the original founders - who knew the system perfectly. So things would get posted and you'd be like "oh, that's a good starter task..." and instead a "core" developer would pick it, do the one line fix, and then just push it straight to the master branch (or PR it but it would get approved within minutes in their timezone) while I was still trying to get my bearings in the code and tests. Within a month or two the manager who hired me had "resigned", and then I was let go near the end of my probationary period. The whole time I never had any solid work assigned beyond "oh figure out where you can be useful".
• yarg 3y ago
  I've been in a situation where I was set to fail despite the fact that I was actually performing a vital task for the company. Every damned time I set out to implement changes necessary to ensure the maintainability of the project, the boss would bring in an architect (who otherwise never even looked at the project) and he would pull the rug out from under my feet. Every damned time. By the time they realised I was actually useful and regretted the situation I was checked out and ready to walk out the door.
  • Aeolun 3y ago
    Hmm, was your architect also allergic to any kind of risk? E.g. any change was by default undesireable because any change carried more risk than not changing anything.
    • yarg 3y ago
      Nope, just a dude who never bothered to look into who actually shat the bed on the first project that I worked on.
• ww520 3y ago
  This brings back memory of one of my projects. After I had couple years of professional development under my bell, I started contract work on the side. I've done a project with a client and it was a success. They wanted me to tackle a bigger problem, porting their app server from Unix to Windows. I thought how hard could it be, and took on the job. Turned out their server was written in Perl scripts and Perl was not running on Windows back then. After couple days of looking at their code and build system, I told them to either rewrite their server in Microsoft IIS Web server or Perl had to be ported to Windows to run their Perl scripts. They said port Perl to Windows. The naive me didn't comprehend the gravity of such task and took it on. I struggled for couple weekends and realized it's not just the Perl interpreter needed to be ported but the whole Perl ecosystem. It's not a task a weekend contractor could take on. I gave up and told the client the bad news. They just shrugged and said they just wanted how far I could get.
• ChrisMarshallNY 3y ago
  One of my first programming assignments was to fix bugs in a 100KLoC+ FORTRAN 4 codebase. All one text file (300 baud VT-100 CLI). The line printer saw lots of use. No comments. No subroutines (just lots of GOTOs). Helpful variable names, like A32Q3 It was mid-1970s vintage. The original developer was a Bob Ross-looking guy that I wasn't allowed to bother. I was on my own. My most effective tool was a magic 8-ball. Lots of guessing. It helped me to ensure that I would never do that to anyone, ever. It did help me to be better, in the long run. Once you have seen Hell, everywhere else is Heaven.
  • globalnode 3y ago
    similar thing happened to me straight out of uni -- i was less interested however and quit my job. in fact i quit the entire industry.
• khana 3y ago
  [dead]
• pjerem 3y ago
  Same here, and that’s how you start your career with an authentic burnout.
• pipes 3y ago
  Sort of similar, I was handed business critical system to maintain on my own. I was new into the company, and new into that industry too. I was expected to handle business requests, establish good relations with users and run all meetings with them, Sort out the old backlog which was in a total mess, provide constant support, progress stories, create new stories. My manager threw me under a bus early on, we had a pre meeting catch up to decide what we'd discuss with business stakeholders. In the meeting I brought up what he mentioned and I genuinely thought he'd forgot to ask, his response "why would you think that..." Then proceeded to act shocked I brought this up and proceeded to contradict me. If I asked my manager for anything he'd throw it back in my face. I had 18 months of pure hell. Only after I left did I realise I was in a sort of abusive relationship. I heard later he said that my problem was I refused his help. It was a miserable experience, made worse because I pretty much always blame myself if something is wrong.
• helboi4 3y ago
  yeah I had one of these at my first job. Was given a massive task to create the testing strategy for this app that I hardly understood. Nobody seemed to understand the task I was doing and what the limitations were when I asked for help. It just made me dread going to work. 2 years into my career now I feel like maybe I could work something out. Still feels a bit heavy to lay on someone as their first ticket, something that requires deep understanding of the workings of every single part of the application.
• m463 3y ago
  sounds like sort of a 5-why's situation.