Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Lost role due to performance

Options
  • 27-04-2024 7:12pm
    #1
    funkey_monkey
    Registered Users Posts: 8,195 ✭✭✭


    Hi.

    As per the title got shown the door from role due to performance issues. I was in on a 6 month contract.

    It wasn't unexpected, but I'm still in a bit of shock as it was first time this has happened to me.

    It was an OOP project and I know I wasn't performing as well as I'd like. I was brought on with recognition that my experience was not an ideal fit and with expectations that I would get up to speed in a reasonable time frame.

    However, I could just not get my head around the code base. Bug fixes were problematic as I just could not trace the code and find issues. I can't say that their code base was overly complex, it was very big and I stifled tracking objects - even with the debug past of the dev environment, but other new starts have done better than me - so that's not a valid excuse.

    When I asked for help, I would be told where the issue likely was, through their knowledge of the code, not really due to architecture or requirements/design.

    Why I'm posting is that I would like some help and advice on how to get up to speed on a new code base quickly and debugging tips.

    Honestly, my confidence is shot to bits. I've mostly worked on functional programming as opposed to OOP.

    There are more openings in OOP in my location so I want to get up to speed to a competent level.

    How do you all ramp up your productivity when starting in a new role and and guides for debugging techniques?

    Any questions I'll try to answer without doxxing myself!

    Thanks.



Comments

  • Options
    #2
    rat_race
    Registered Users Posts: 987 ✭✭✭rat_race


    Sorry to hear this, at least you're reflecting and interested in improving. Honestly, your good attitude probably wasn't recognised and they've probably lost a good asset.

    The vast of majority of engineers whom I have worked with are over-confident and usually completely useless; are just additional workload to manage, for the 10% of competent engineers who actually do all the work. Oh, and it often takes several months before anyone is productive.

    Anyway, OOP is generally where it's at. If you're a usually functional/procedural programmer, it might seem daunting.

    1. The biggest advice I can give is: relentless curiosity. Be super curious how and why stuff works (even in a large codebase) — never settle for "it just does it that way", and spend as long as it takes to understand it.
    2. Second, know your tools inside out (IDE, command-line tools, whatever), from shortcuts to debugging, etc. — I cannot tell you how many engineers I see spending half their day complicating simple repeated tasks. Get your projects setup in such a way that you can quickly see/search, just about everything, in one window. Get your IDE working, 100% — no red lines, no stuff that doesn't work without you knowing why, etc. Understand it.
    3. Read or watch tutorials on OOP, and practise -- get simple yet reputable open source projects and step through them and ask yourself why the engineers put them together the way they did. It'll all come together.
    4. Learn how to write good tests; tests are where it's at. If you can write tests, your actual main code will end up much better, but also understanding pre-existing large systems becomes much easier (e.g., where a test is your starting point to invoke something).



  • Options
    #3
    funkey_monkey
    Registered Users Posts: 8,195 ✭✭✭funkey_monkey


    https://www.boards.ie/discussion/comment/122077581#Comment_122077581

    Thanks for that. Any tips for speeding up gaining knowledge of the code base? It was over 1,000,000 lines and although broken down into areas there seemed no way to figure out how it where things were done without knowledge or experience.



  • Options
    #4
    croo
    Moderators, Technology & Internet Moderators Posts: 1,334 Mod ✭✭✭✭croo


    https://www.boards.ie/discussion/comment/122078028#Comment_122078028

    It's been a few years since I worked on large applications so I might be out of date and these suggestions are not specific to OOP, but…

    I still like to create diagrams to help me understand the structure.

    Understand patterns; if the application you were working on uses them, you can immediately understand what is happening as soon as you see a reference to the pattern name that would typically be in the class name.

    Know the common frameworks in your choosen OOP area, e.g. in the Java world Spring is very popular, in the C# world .NET etc. If the application is built with one of these framework then learning it independantly of the application will make it easier to understand the application.

    And again not strictly OOP, but most BIG business applications I've worked on - no actually ALL such apps, have two broad areas - an "application" framework and then modules that use this framework to implement business logic. So menus, screens, security, printing, flow & messaging would be managed via this "application" framework, if I'm working on the business logic areas, I want to know how this works or more correctly, how I use it… but, initially at least, I'm not interested in its implementation. Being able to differentiate between the framework & the business code is helpful in reducing how deep you need to go when debugging. Unless it is the framework code itself you are assigned to!



Advertisement