Landed a software development job that operationally is a mess and has little potential career growth. What can I extract from this?

Question

I am a recent graduate on my first full time software development job. The job promised mentoring and effective development, but has in the 6 weeks I have been here provided none of those things.

The major problems with the environment:

1. The lead developer (not my boss) openly subscribes to the thinking that a lack of documentation is a form of job security. As a result, nothing is written down. There is not even a written list of libraries used or the git repos we have, yet alone comments in the code or an overview of what is the current chunks of code do. In addition, he doesn't want people figuring it out for themselves either, so he just tells every other developer to stop work if they need help and he will do that section. If you cannot complete a block of work 100% on your own, it gets taken away from you.

2. The manager (my boss, who is technical) is seemingly unmotivated and uninterested in the work. He takes every Friday off and spends the rest of the time in his office. When I have asked if there is anything I should be doing, he promises to get back to me and doesn't. As a result, I frequently have nothing to do except Udemy courses.

3. We use Agile/Scrum which apparently is about giving developers all of one sentence to work from in sprints. I am currently assigned to work on the user login tracking. The entirety of what I have to work on for the two weeks (changing a few words for anonymity) is "the system should keep track of when a user logs in and any relevant information about them logging in." What does "relevant information" mean? Nobody knows. Who is going to use it? They aren't sure. I was just told to find random stuff to record and while I have done that, it is just what I would want. Sprints also require that developers estimate how long a feature will take, but as we have no idea what will be requested before the sprint meeting, we are giving estimates based on adapting code we have never seen. In addition, the project manager often breaks up tasks into similar items and will assign them outside the sprint planning, so two team members can easily end up working on the same thing and duplicating code.

What is the best way to extract career value from this mess?

I (and the other 3 developers on my project) don't get challenging tasks as the lead takes them to prevent the spread of knowledge.

I don't really get to collaborate with anyone. Boss is absent. Lead doesn't want anyone else asking questions or really figuring out the code. Other devs also seek escape and spend their time pushing concepts which will allow them to learn new technologies (projects I am unfortunately not assigned to).

For example, the mobile app will be getting its third complete rewrite in three years. We used to do native, moved to Xamarin, and then now the dev on that project is pitching Flutter.

I don't get serious practice in meeting actual business needs as apparently in Agile the sum of requirement analysis for two weeks of work fits on a post-it.

Other than basically meeting a mediocre standard and transferring all the time to an independent project of mine, I don't see a lot of opportunities. What is the best way to have a strong market value to jump 8 months to one year from now?

Answer 1

1

The lead developer (not my boss) openly subscribes to the thinking that a lack of documentation is a form of job security. As a result, nothing is written down.

2

The manager (my boss, who is technical) is seemingly unmotivated and uninterested in the work. He takes every Friday off and spends the rest of the time in his office. When I have asked if there is anything I should be doing, he promises to get back to me and doesn't. As a result, I frequently have nothing to do except Udemy courses.

Yes you do. See 1)

If no one else will document, then you can/should.

3

We use Agile/Scrum which apparently is about giving developers all of one sentence to work from in sprints.

No it isn't (except on your project). If you were developing waterfall (which seems to become renamed the V method recently), you would still get as little direction.

You have a big decision to make. Your options are the ever popular "polish your CV and start looking", or stay, knuckle down, and try to change things.

With only 6 weeks, you could simply walk away and not even mention the job on your CV.

Or, you can stay and try to make a go of it. If you stay you probably won't get much help (from the lead developer or his boss); the big question is whether you will meet hindrance. If you expect that you will, a career move is indicated.

You could start documenting things. Run the code through DoxyGen if it supports your language, or look for something similar. Start a wiki. When you figure out what some code does, add comments. Add unit tests, if you can.

Approach your team mates. Sounds like they have given up. Ask them if they would be willing to contribute to a wiki. Maybe someone already tried and met resistance - they will know, and that can help you make a decision.

4

The lead developer (not my boss) openly subscribes to the thinking that a lack of documentation is a form of job security

Read about he bus factor. Perhaps mention it to the boss/PM? If the lead dev walks under a bus/marries & moves away/moves away to care for a relative/etc what will happen? I have seen this, and it is not pretty. In fact, if he is so indispensable, what happens when he takes holiday?

5

In addition, the project manager often breaks up tasks into similar items and will assign them outside the sprint planning, so two team members can easily end up working on the same thing and duplicating code.

Does not bode well. It really does sound like a text book "how not to run a project" and you might well be advised to look around. Did you get any other offers? Might those companies have something for you?

This is not how you want to spend the next 40 or 50 years. If you tough it out for two, will you be employable elsewhere afterwards?

Tl;dr - change it, or get out. The attitude of your teammates should be an indicator. The attitude of your boss and PM is already an indicator.

Answer 2

Start looking for a job now.

I was in a similar situation in my first IT job after graduating.

Where it was apparent that it wasn't a very good job from the start - I convinced my self to 'at least stay for a year, because it wouldn't be a good look to leave early'.

The problem with that kind of thinking, is that:

1. It might take longer than you think to find a new job.
2. You can leave now while you have that 'new grad smell'. In my case, after a year when I started looking for a new job - I now had a year's experience with an obscure technology. Having a year's experience of an irrelevant technology probably made it harder than being a new grad with no experience. If you're worried about answering 'why are you leaving your job' - don't worry too much, saying 'I want to work somewhere with good practices' is going to be appealing to people who have good practises.
3. There's the opportunity cost of what you might otherwise be learning. If you were working somewhere else you might be learning much better skills.
4. Working in a place with bad practises can be bad for your mental state. If you're working with undocumented code, it's frustrating and stressful and can lead to burn out.

Answer 3

Look for a different job. Until you find one with a legally binding job offer, you stay where you are, because it puts money in your pocket.

In parallel, you can try to improve things at your place. Even if it comes to nothing, it is a good learning experience. Write down what is happening, why it is wrong, and what are the risks for the company.

The biggest risk is that with a team leader like this, the company will never manage to hire an experienced developer and keep them. For you it's the first job, and you think hard about leaving. Imagine what a future you with 5 years experience would do in that situation.

While people talk about "bus-factor" (what happens is the lead is run over by a bus, or by a colleague who has had enough, or on the positive side wins the lottery), that's actually not that big a risk. It will be expensive, but the company can hire someone who is really good at their job, for a good salary, and it will be fixed.

The biggest cost comes from the fact that the lead runs things in a totally inefficient ways. If a junior developer has questions, you don't take their work away as a lead and do it yourself (if the lead gave the job to a junior, then it is a job that the lead should never touch), you help them to overcome the problem, if it's something that needs documenting tell them to document it, and then you let them get on with it.

It seems you have one PM (and everyone knows he is not doing much), one lead (but nobody knows what he is doing), and three developers who don't do any useful development work. That's not your fault, obviously, but you can try to do your best to change it.

PS I can see a lead developer position opening once your management wakes up. Admittedly you’d have to be very good to get that.

PS. A replacement for the team lead would mean the company would suddenly have one effective team lead and three effective and motivated junior devs. They can achieve a lot.

Answer 4

What is the best way to have a strong market value to jump 8 months to one year from now?

Given the information, your best outcome is a good reference and whatever you manage to educate yourself with. Both of which are quite valuable assets.

Don't expect too much when you first join the workforce.

Answer 5

Getting professional experience is more than just improving your technical skills with real-world programming challenges, but also learning to navigate your way through a dysfunctional workplace.

No company you'll work for will do things the right way, and even less the right way for you. Startups move fast and break things, big established companies drown in processes and paperwork. Don't get me wrong, your current situation sounds pretty bad, but without seeing it I don't know how much is that bad and how much is the "new job" effect where everything is either amazing or a dumpster fire.

There's no right or wrong here. You can stay and learn how to survive a dysfunctional company, and even make it better (e.g. by documenting as some people were saying). You can leave to try and find a better company, but the grass will always be greener somewhere else. Either way, you will come out stronger and with a lot of experience about how to work in a real-world company, even the most dysfunctional ones.

Answer 6

You should quit.

• You are not long there and there is already enough to warrant leaving. It is not even two months and you already find a pile of poor practices.
• More importantly, since you are not long there, you are not really invested in neither the project nor your career in this company. So nothing stops you.
• I have worked with such management/leads before, nothing is going to change in this company. Your boss, according to your description, has no interest in improving and increasing productivity. What your lead is talking about w.r.t. job security is something I heard before, but even in the cases I heard people mention something like this, I have never encountered somebody who actively deters colleagues from documenting or learning. This is something that should be brought to the attention of management and ultimately punished - but again, I have a feeling management is not invested enough in the topic.

If you wanted to leave on a sour note and at least cause change by going away, you could hand in your notice and have a talk with management, explaining to them why the development practices in house are directly harmful to the business. However I would advise against this, even though I myself did that back in the day. This has two reasons:

1. Businesses like this don't change. They keep somehow scraping together money or go bankrupt, usually there is one person who is kind of the heartbeat of the whole thing and if they ever went away the company collapsed. In any case, your words are likely to never be heeded, so essentially all you are likely to create is some temporary strife.
2. In addition, I am looking at this from your perspective. You have zero to gain from either trying to help the company as you leave or to try and tear them a new one as you leave, other than maybe some personal satisfaction. Other than that there is just no benefit. Chances are you burn a bridge and whatever advice you came up with is never put to any good use.

I know this is kind of dissatisfying, but just leave. Be professional, call a professional reason for why you want to leave and then forget this project ever existed. In constrast to another answer I don't think it is your job to establish documentation if your lead actively works against this and management doesn't care. Ultimately you are a developer, not a project manager. Your job is to produce code. If the decisions by management and head of development are disastrous, you can point it out, but if they decide not to heed your warning, then this is where you should draw the line. Especially if your lead does not want you to document I don't see why it is your job at all to do it. It is not.

Edit

Just an addendum: Personally I also would keep working there until you got a new contract. Don't make this company's problems your problems.

Answer 7

Ask to schedule a meeting with your boss about feedback. Get him to write down a specific time before you leave the room, and if he doesn’t, email him repeatedly until he does schedule a time (though obviously don’t spam his inbox).

In that meeting, tell him exactly what you told us. Ask him if he’d be willing to talk with the senior engineer, since you believe that his behaviour is harming the business since it’s increasing risk (look up bus factor), while also preventing the other programmers from contributing meaningfully. You’re getting paid a salary, and you’re afraid that his actions are preventing you from properly earning it - and that means your job is at risk the next time there’s layoffs.

Additionally, ask about getting your Agile tasks to be given proper acceptance criteria, so that you know what the heck you’re supposed to be doing. At the moment, you’ve only got Agile half-implemented.