Job question - not great at dealing with complex code bases. What to do?

experiMental

After a few years of experience in development, I have realised that I am not very good at dealing with complex production-level code bases, to the point where I'm too slow and inefficient in my job.

I was flying with less complex code bases, but once I was faced with more complex ones, I was struggling.

If I want to continue being a developer in future, would many employers expect me to deal with complex code bases, even if I will be working on fairly simple things on a daily basis?

In general, I'm much better at creating things than analyzing them.
Would a switch to something like system design/architecture be a better option?

TrueDub

It's not easy to keep an understanding of an entire complex codebase in your head - and nor is it necessary, all the time. Normally you'd work on understanding the bit you're working on, and changing that.

My suggestion to you: as you go through the codebase, document what you learnt, preferably on a wiki, but in a text file if all else fails. This way you can go back to your notes to refresh your memory when you need to. You'll also make yourself popular with your fellow devs, if you share this work as you go along.

jester77

Getting into design/architecture sort of contradicts what you wrote in the rest of your post.

Any half decent code base will be built using common design patterns. These patterns are code agnostic, so if you understand the patterns it should not be too difficult to get into a code base. If you want to get involved in the design and architecture you will need to have a good understanding of these patterns.

L.Jenkins

I worked with WebSphere Commerce during my time in IBM and the code base was far too vast and complex for one person alone to understand. So it was split into sub components with an owner for each. When it comes to large complex code bases, maybe you could do the same. Break it down into sub components and have a team member own each component of the code base, then change component every few months to gain further understanding of the code base.

Trying to learn or understand it all at once can be too much.

14ned

experiMental wrote: »

After a few years of experience in development, I have realised that I am not very good at dealing with complex production-level code bases, to the point where I'm too slow and inefficient in my job.

This is great news. If you are anyway a potentially great developer, you should be feeling exactly this at this time.

experiMental wrote: »

I was flying with less complex code bases, but once I was faced with more complex ones, I was struggling.

If I want to continue being a developer in future, would many employers expect me to deal with complex code bases, even if I will be working on fairly simple things on a daily basis?

In general, I'm much better at creating things than analyzing them.
Would a switch to something like system design/architecture be a better option?

Every engineer prefers to create their own code instead of working on other people's code. Working on other people's code is usually (but not always) an inferior experience to working on beautifully architected and written code, yet employers almost always want the latter and not the former.

Even when you do get to design and write an entire codebase from scratch, very few employers will permit you to properly finish it. It doesn't make cost benefit sense for them, and it will leave you feeling frustrated.

It is for these reasons that many of the very top developers will try getting a software library into one of the open source peer reviewed library collections in their free time. The effort will take (usually) years, the peer review process is brutal, but success means that when you next interview at Google you can skip half the interviews because you'll have achieved what only maybe 1% of software developers ever do.

So that's my suggestion to you: invest eight hours per week of your free time into getting a library past peer review. You'll get to design everything, write everything, and then watch your efforts get ripped to shreds during peer review. You'll then repeat until you pass, and then probably never do it again , but it'll turn you from the kind of developer you are now into a much better developer, perhaps even one who gets invited to speak at the big global corporations for a hefty fee.

Niall