1. 15
  1.  

  2. 11

    Seeing this makes me think this:

    Qualities of a codebase that’s easy to get familiar with:

    • The vector from UX/UI aspect to line of code responsible for it is as straight, direct and obvious as possible
    • Standing up a local dev env of the app(s) should be as painless as possible
    • Local dev installations should be as similar to other envs (production, staging, other dev envs) as possible
    • Debugging on staging (or equivalent) envs should be easy
    • The system and infrastructure of the app should be as simple and easy to work with as possible: frameworks, code dependencies (Ruby gems, npm modules, whatever), linting, pull request service, CI, CD, containerizations, cloud/computing services, third-party services (e.g. SMTP trapping, logging, error collection, app health, uptime, status page / outage PR management) – each chosen and put in place deliberately because they were proven to add value to the business over and above what value would be gotten by not having it at all

    I get grey hairs thinking about how many times in my career I couldn’t just code for a given task because I had to wrestle with (lack of) the above.

    1. 10

      Don’t ask anyone for help unless you are really stuck

      This is very bad advice in my opinion. Assuming this is directed at motivated developers, the chance that someone will struggle for hours or days to decipher some old structure that badly needs refactoring is much larger than the chance that she will overburden the senior programmers with elementary questions.

      If anything, senior programmers getting too many questions from juniors can be an extra motivation for the seniors to spend more time on simplifying their contributions.

      1. 5

        For me “pick a trivial bug, fix it” falls into the same category. For someone unfamiliar with a codebase it is hard to determine if a bug is “trivial to fix”. I can’t even count how many bugs I encountered that looked trivial in the first place but then turned out to be hard to fix.

        Instead of trying to grasp the code base alone I would highly recommend to look for someone who is experienced with the application/service and work with them together, e.g. by pairing. At least when I started my professional career, I wished I had a buddy who teached me how to debug/read/understand the code base I was working on, especially since there was no or very lacking documentation.

        1. 3

          Agreed, as someone reading this graphic who’s just started a new role, I feel like this advice is well-intentioned but not refined enough. I think what it’s trying to get at is that you really should try your best to understand the code alone, but there’s a point at which struggling to understand the code without someone else’s assistance yields diminishing returns. Obviously, don’t go asking questions that you could easily Google and find on StackOverflow left and right, but if there’s a question more closely related to the underlying company-related code style/infrastructure, I don’t see a point in not asking a question right away. Any reasonable senior engineer won’t scold you for asking questions, since they were once in your shoes too!