1. 14

  2. 6

    You’ll need to work without documentation

    The advice in this section has summed up the majority of my professional life. Granted, SQL and C# are usually documented, but the majority of other things I work with from a business perspective often aren’t. Debugging and code reading and talking to coworkers has been very helpful.

    1. 1

      This hit me as well. I’m just starting out, but I find myself in a more challenging position once the documentation runs out. Getting more comfortable in the source us a priority for me.

    2. 4

      Those strike me as fine points - but maybe a bit limited.

      If I had one piece of advice I’d want to learn as a junior developer, it’d be “focus on people and business problems, not technology”.

      Learning that I wasn’t paid to write code but to deliver business value took me a (embarrassingly long) while, but when I got it I went from “a good programmer” to a recognized expert in my company.

      And I’m just starting to learn that I can deliver even more value by focusing on mentoring and training my coworkers.

      1. 3

        You confuse readibility with style. Style should be consistent but readibility means good abstractions.

        1. 1

          I recently had an encounter with a code base filled with duplicative code, excessive logging, poor abstractions and long methods. Oh, and 50-100 (pretty printed) lines of SQL compressed down to 4 lines of concatenated strings.

          It was typically 2-6 lines of logging, 2 lines for try/catch, 4-6 lines for some braces and then maybe 1-2 lines of logic filled with chained method calls to things that should have been readily accessible. Repeat that for a few hundred lines and you’ve got yourself a “run” method ! Time to move on to the next class.

          There were no primitives to work with. Just masses of code globbed together. It was impossible to read. @_@

        2. 1

          There’s a broader point here. Debugging strategies are generally worth more than the ability to write code quickly.

          This one I would emphasize way more. The ability to find a relevant section of code, set a breakpoint for your debugger and then hit it with a with a relevant execution of the program is a super power. Combine this with the courage to dive into code that lies outside of your system’s boundary and you will never have to fear the situation that something is going wrong and you have no clue what is happening. Because you can find out!