1

My story goes something like this: I accepted my first full time position in May of last year with a large-ish company (1000+ employees). Because of some mitigating circumstances I didn't actually start until around this time of August last year. Now that I've been working for a year though, I've become rather dismayed about my employer. As a result I've resolved to look for a new job, but I'm worried that even if I move somewhere else it'll be more of the same.

So let me describe a few things that bother me:

  1. When I started the position my manager was on vacation for three weeks, along with his usual delegate. About three weeks after he returned he then took a job elsewhere. When that happened my team was split with three other members going to another group along with the custom software products they were the experts for. The remaining members, myself included, were spun into our own new team.
  2. Feeding off of item 1, my first task was to write unit tests (of which, by the way, there were almost none of in the first place). As it turns out the product I was writing these tests for moved to the other team and that manager chose to reject my unit tests because no one in their team could vouch for them.
  3. Shortly after my team split I was reassigned to a major project under the leadership of a much more senior developer. As I learned later he wanted to do the entire project on his own in the first place, so it's no surprise in hindsight that during this time his mentorship was quite limited. A couple of months later he was transitioned to a different team, but not before leaving me with a very limited proof of concept, but no real design, and ensuring that code was developed using tools that were still being piloted within the organization. This created all sorts of problems later because of the intricacies of our very custom build environment. It's also ensured I'm the only one on the team, and potentially my department even, who now understands the technologies and frameworks in use well enough to really work on the product.
  4. So only maybe four or five months into my first job hired at the lowest developer position, I became the technical lead for the project and honestly I've been terrible at it the whole time. The project was run in a waterfall manner, which ended up meaning we were required to start development well before requirements were finalised and that the high level design was essentially a bunch of interconnected black boxes without enough specificity to be useful and were not very grounded. Thus I was asked to lead other team members when I myself could barely keep afloat writing the features (and as a consequence I readily admit the code is terrible). Not long ago then, the product became important enough to make its success part of the company performance metrics. This frightens me to death because I know intimately how poorly written it is, let alone how robust it was designed to be. Not to mention the two "experts" on the product, myself and one other, have less than eighteen months total working experience.
  5. Regarding my organization... It is ludicrously risk averse and slow to adopt "new" tools. Our build tool is custom, our testing teams write very limited amounts of automated tests, and code reviews are often done by passing around spreadsheets. This concerns me because it means much of what I learn is useless outside this organization.

So on some levels I've got immense job security, but ultimately I've become so stressed by my position I often hope I'll screw up badly enough I'll get fired. Many days I go into work solely out of a self imposed duty and obligation to keep my co-workers from having to make sense of and extend my awful code and keep the product progressing.

Are any if these experiences at all common? Is it fair of me to treat them as the kind of red flags that I have been?

Edit: Understandably this question was put on hold since I didn't ask a question with a real answer. Before I add a few more substantive questions, I'd like to thank Cameron and Walfrat for helping me anyway. I think there are already some valuable pieces of advice there about ways I can improve the current software development practices, but I do have another follow-up since I am trying to leave: What can I do to lessen the blow to the people I work with? I'd imagine improving the code comments for a start. And I was thinking about creating some write up for improvements on the current design. Is there anything else I can do? Anything better than what I've thought of so far?

closed as off-topic by HorusKol, gnat, mhoran_psprep, Chris E, Masked Man Aug 4 '16 at 16:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – HorusKol, gnat, mhoran_psprep, Chris E, Masked Man
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Unfortunately, it doesn't seem to be unusual for people to be working in bad companies/organisations. Luckily, there are plenty of good companies/organisations out there. – HorusKol Aug 4 '16 at 6:42
  • 2
    "but ultimately I've become so stressed by my position I often hope I'll screw up badly enough I'll get fired." This is a signal that it is time for you to move on. Don't let loyalty stop you from doing what is best for your own health. – HLGEM Aug 4 '16 at 18:42
  • 1
    PoInt 4 is something you can use to show what you have learned from this job. You have learned how important some things are and how easily things can go wrong when you don;t do them. Those are very valuable lessons. You also have a view from the tech lead side that will help you as you go back to being a junior developer. Your world view of what is important has expanded. This is a good thing even if it was learned painfully. It can also be a huge selling point to another organization. Someone who learns from mistakes is valuable. Someone who knows how not to do things is valuable. – HLGEM Aug 4 '16 at 18:47
6

As a result I've resolved to look for a new job

That's a good starting point. If you're not happy in your job then it's totally reasonable to find something that suits you better.

As for the unusual circumstances, let's go through them one-by-one.

  1. Random re-org. This is, unfortunately, more common than most of us would like. When a manager leaves it makes things difficult for senior leadership. In an ideal world they would just hire a new manager and things would carry on as normal. In practice that's very difficult to do - it's just hard to hire new managers fast enough to fill the gap. It's reasonably common to re-organize teams amongst the remaining managers, or to combine two teams under a single manager. This isn't necessarily a bad thing. It can be an opportunity to align things better, but it can, of course, sometimes just be a panicked "we gotta find a home for all these developers".

  2. Rejecting unit tests because "no one would vouch for them" is bizarre. The tests vouch for the code, not the other way around. This suggests a culture that doesn't value code quality, has a "not built here" attitude, and is definitely a red flag.

  3. This is a major red flag. Single-developer projects often fail. You're seeing some of the reasons why they fail: Little or no design review, no-one challenging decisions (such as using pilot tools for a mission-critical piece of software), and, most importantly, siloed development. As soon as the domain expert leaves (or goes on vacation) things fall apart. If your management chain is not actively working to discourage this kind of pet project approach then that's a problem. This is not totally unusual in the industry but it is definitely a red flag.

  4. An even redder flag. If senior leadership is trusting two junior developers with a mission critical system then they are asking for trouble. That's not to say junior developers can't work on mission critical stuff, but delivering a complex technical product requires a lot more than just bashing out code. You're already seeing this: lack of design, poor code quality, and questionable development practices are all signs of a project that is likely to fail. Management's decision to not assign senior engineers to an important project indicates either hopeless optimism or that they really haven't thought this through. I really hope this isn't common across the industry, especially in large companies that have the resources to assign senior people to important projects. In startups sometimes there just aren't enough seniors to go around, but if you have 1000+ people then this shouldn't be happening.

  5. This is a great opportunity for you to make things better. Pushing for better code quality (through extensive automated tests and a robust code review process) is a great way to make an impact, and to demonstrate to your next employer that you are someone that will step outside their immediate responsibilities to drive improvements. You will need to convince people that testing and code review is important and that can be tricky. Gathering data on the number of bugs that make it into production can be a good place to start. A lack of focus on quality is depressingly common, but it's relatively easy to fix. This one is less of a red flag because it's something you can directly address and lead by example.

3

Are any if these experiences at all common?

I'll focus on this points since Cameron Skinner's answer cover already the red flag part and looking for a new job.

I think you have quite win the lotery there, all the things you got there are things that exists but i think we can say it's pretty rare for all of them to be on the same place at the same time.

So :

  • Reorganisation are common
  • Single developer project still exists, but is still less common that some years ago.
  • Becoming the "expert" as "being the only one that know something about it" is quite common too.
  • Seems like that senior developer just don't want that project to goes well if it's not him. I have seen quite some non-technical people think they can replace senior by multiple junior (this, is common) thinking this will work (google will do the rest... or not!). However a senior developer will know that you just won't make it, at least not without a looooot of stress, extra hours, and so on.
  • Changing tools is not only about changing tool often, it's about changing process of delivery and validation. This is why it is always slow (and going too fast should raise a red flag), if you want to have a chance to get the company adopt thoose tools, you have to show how those processes will be better with the new tools.

Unless there is a chance that they drop this project that is just a failure from the start, i will just go for a new job. You will always see some of those problems again but there is really few chance that you got all of them again in the same place like this.

Not the answer you're looking for? Browse other questions tagged or ask your own question.