21

I started a new job as a software dev about 4 months ago and have been mostly learning. There's about 8 new developers working in two teams on the same project.

Initially, I thought the slow process was due to everyone having to be worked in (with 8 new people and only 2 experienced devs, there's a lot of learning to be done) but it's been 4 months and all the signs seem to suggest that the current pace is actually the accepted pace here.

But to me, it just feels incredibly slow. Features that from previous work I would expect to take a few days are scheduled to take a few weeks. The worst part is they end up actually taking that long to build, too.

I feel a combination of a poorly set up framework, lack of documentation and a really slow execution speed cause things to take incredibly long. But this is a project that's been under development for about 2 years already and I don't think saying "all of this is terrible, we should start over" would be well received.

So now I feel demoralized; I feel like I should be able to accomplish more, but then every day feels like I'm fighting the system instead of the problem I'm supposed to be fixing. I've mentioned this at the previous retrospective, but the experienced developers don't seem to think it's an issue and the other new developers in my team don't seem to speak up about it much.

Is there any good way to adapt to tools that aren't as good as you were used to and can't easily be replaced? Or should I just change jobs?

I like the company and the people, it's just that the tools and the project we're working on are ruining my motivation and it's even starting to spill over into my time at home.

  • 8
    Start fixing the system..? That should take up enough of your time to make the pace quicker:-) – Ben Jul 28 '15 at 13:37
  • 5
    Unfortunately, that's not my call. The last time I tried fixing at least the lack of documentation, it wasn't very well received. – Erik Jul 28 '15 at 13:38
  • 3
    I've been hired as a medior/senior, with about 5 years of experience. – Erik Jul 28 '15 at 13:42
  • 4
    "Features that from previous work I would expect to take a few days are scheduled to take a few weeks" - Did those types of features actually take only a few days in your previous environment? – Brandin Jul 28 '15 at 19:59
  • 5
    I think you've learned a couple new questions to ask the next time you're in a job interview... – NReilingh Jul 29 '15 at 0:59
18

As a developer, find new ways to grow and develop yourself. Growing as a developer does not mean taking the linear path of latest tools, latest design patterns and making a new of everything. Some of your best experience and growth can come from working with cumbersome systems and applications. More companies than not have this kind of issue. Not every firm believes in investing substantial capital in their IT infrastructure every five years or so.

What this current position can provide you is the experience to show that you know how to work on a team and make incremental improvements to the system and company. You're not just another hip with the latest and greatest developer; but a real developer who has learn how to deal with real problems and systems reflective of business.

Your best approach to adapting current tools is to look for frameworks or modules that can help you in your flow and make suggestions to management for tools and areas that can benefit from other tool sets not already available to employees.

I recommend you combat your feeling of being demoralized by looking at the opportunity you have to make a positive impact while you're there and help modernize their practices. Down the road you'll likely look back in hindsight and appreciate what this experience offered you in the developer you'll inevitably become.

  • Thanks for sharing that growing as a developer doesn't always mean taking the path of new tools and tricks. I've actually managed to switch functions to one more geared towards improving the process and it's starting to pay off now. – Erik Sep 28 '15 at 11:31
11

If you have the time and ability, deliver the day job as asked, but also work out what would be needed to improve the current environment. Include:

  • Tooling
  • Communications
  • Documentation
  • Templates
  • Processes
  • Framework
  • Culture
  • Ownership / Responsibilities
  • even Organisational Structure

Because it is very hard to change that sort of culture, and the only ways to do it are as a CEO sanctioned 'Big Bang' or by demonstrating better things that can be swapped in for outdated/inefficient ways of working.

Describing it as a problem to management may not be helpful, but describing the benefits you can bring with this change here, then that incremental change are likely to be given more leeway.

Be aware you may need to describe and justify every potential benefit, and ideally show where that change has benefited another organisation, otherwise you may look like the sole dissenter in a coherent company.

It can work - I have done it to some degree with a global bank, and have successfully made major changes in smaller organisations - but it is not easy, it will take a lot more time than you think, and at first you will not be thanked for it as change will make everyone's life more difficult around you.

11

This seems like the perfect example of a poor fit in a position. Others are able to handle this environment without much frustration so it boils down to you not fitting in the corporate culture. You can make suggestions and put effort into changing the culture but as Rory noted that is not an easy task. At this point you need to decide whether it is worth your effort to try to shift it or if your effort is better spent finding a different environment that would be a better fit.

  • 2
    Sorry, but there are many more possibilities than this. While this might be the reason - i.e. there are good reasons why the toolset is set up like this - it's also possible that the toolset is like this because of inertia. Either the team doesn't realise they could do better and be more productive, or they don't have the available effort to make improvements. – DJClayworth Jul 28 '15 at 14:02
  • 8
    @DJClayworth Based on OP comments attempts at change have been poorly met I stand by the statement that it boils down to deciding if it's worth the effort to change the culture. – Myles Jul 28 '15 at 14:35
  • I'm inclined to agree with Myles. Sometimes you can go into a workplace, certain that even if things aren't great, you'll be able to improve them. Sometimes, that'll work. Other times, corporate culture is so strongly entrenched that change - even positive, efficiency-improving change - is borderline impossible. Ideas like 'change control' and 'risk prevention' can also mean 'wilful stagnation'. – yochannah Jul 28 '15 at 20:33
4

I've seen your problem as a developer and as a director, too. I've seen that people like a project idea, share the same goals, share the same values, but they cannot live with some aspects of the methodology or corporate culture.

You question tells me that you're looking for a change.

The fact that your company hired 8 new people tells me that your company is looking for a change, too. I think it would be a good idea to understand the nature of the changes your management is looking for. Do they expect that 8 people will be more effective and deliver more? Or do they also expect that the new people bring new habits, change the culture? Do they plan to add new management to your team? Or have they added a new manager who is also learning now? I think it would be really great if you could find someone in the organization to talk through all the future plans of the company. Does your management see the issues? Do they know how they compare to industry benchmarks in terms of speed, tools and quality? Are they open to discuss at all?

The above questions give you a better idea of what you can expect here. I would not be afraid to ask. It is always better to ask than suffer and leave silently.

Changing your own environment, your system, yourself is an option, but it's a naive one. People and companies stick to the current script until it is not proven wrong. Projects often accumulate delays, low quality and cost overhead for months or years before management takes serious actions. I did a lot of damage control of f@*d up projects before, I know what I'm talking about. Keep in mind it is top stakeholders who need to initiate radical changes. You can always start the discussion, but it is not a developer discussion. You need to talk money, because top level decisions are made on a business case basis. In a developer discussion you can add a few new tools, but you cannot change the culture, the organization, timelines or budgets.

I think if you find someone in your new management who feels the same pain and wants a change, and you see a good probability of a change happen, this may be a good place for you, because new ideas will be needed and you'll probably get an opportunity to play an important role.

Without change, I think you'd better start looking for a new job. My experience is that such issues make people leave if there is no positive change.

0

You have basically three choices: Do something to increase the speed of your work (which is through no fault of your own so slow that it annoys you), accept the slow speed and learn to live with it, or find a different position.

Accepting the slow speed and living with it isn't really good for your career. Quite obviously there are people who would absolutely love your job, but they will get a shock if they are have to find a position somewhere else. Finding a different position is at least inconvenient. So can you improve the speed of your work?

There may be simple things you can do. If you are writing C++ code, I have seen compile times reduced by a factor 4 by using pre-compiled headers. I have seen RAM starved machines suddenly get incredibly fast by adding more RAM, or an SSD drive (this is one $100 and one $200 investment, in your position probably a good investment even if it comes out of your own pocket). There may be different things that you can do in your position.

-3

The problem is your unrealistic notion about 'accomplishing' something and 'motivation', not the company or its slow pace.

You need a reasonable amount of money to live. In order to get something you need to give something. So you give your skilled labor developing software and get money (and benefits) in return. It is a simple, straightforward exchange and nothing more. You do not slack off in your work because you are a fair person and you want the exchange to be fair to both you and to your employer. That is your motivation.

Let go of silly, illusory, imaginary, empty notions like 'accomplishment', 'career', 'personal growth' and other nonsensical, HR and managerial buzzwords. If the company is happy with a slow pace you have no reason to complain unless they work at a slow pace until just before a deadline and then suddenly force you to overwork to meet that strict deadline.

  • Or unless that slow pace will cost his job, since the team does not provide enough value-add to the company. – Alexander Jul 31 '15 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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