1. 57
  1. 16

    As a junior developer doing my best to learn as much as I can, both technically and in terms of engineering maturity, I’d love to hear what some of the veterans here have found useful in their own careers for getting the most out of their jobs, projects, and time.

    Anything from specific techniques as in this post to general mindset and approach would be most welcome.

    1. 36

      Several essentials have made a disproportionate benefit on my career. In no order:

      • find a job with lots of flexibility and challenging work
      • find a job where your coworkers continuously improve themselves as much (or more) than you
      • start writing a monthly blog of things you learn and have strong opinions on
      • learn to be political (it’ll help you stay with good challenging work). Being political isn’t slimy, it is wise. Be confident in this.
      • read programming books/blogs and develop a strong philosophy
      • start a habit of programming to learn for 15 minutes a day, every day
      • come to terms with the fact that you will see a diminishing return on new programing skills, and an increasing return on “doing the correct/fastest thing” skills. (e.g. knowing what to work on, knowing what corners to cut, knowing how to communicate with business people so you only solve their problems and not just chase their imagined solutions, etc). Lean into this, and practice this skill as often as you can.

      These have had an immense effect on my abilities. They’ve helped me navigate away from burnout and cultivated a strong intrinsic motivation that has lasted over ten years.

      1. 5

        Thank you for these suggestions!

        Would you mind expanding on the ‘be political’ point? Do you mean to be involved in the ‘organizational politics’ where you work? Or in terms of advocating for your own advancement, ensuring that you properly get credit for what you work on, etc?

        1. 14

          Being political is all about everything that happens outside the editor. Working with people, “managing up”, figuring out the “real requirements’, those are all political.

          Being political is always ensuring you do one-on-ones, because employees who do them are more likely to get higher raises. It’s understanding that marketing is often reality, and you are your only marketing department.

          This doesn’t mean put anyone else down, but be your best you, and make sure decision makers know it.

          1. 12

            Basically, politics means having visibility in the company and making sure you’re managing your reputation and image.

            A few more random bits:

        2. 1

          start a habit of programming to learn for 15 minutes a day, every day

          Can you give an example? So many days I sit down after work or before in front of my computer. I want to do something, but my mind is like, “What should I program right now?”

          As you can probably guess nothing gets programmed. Sigh. I’m hopeless.

          1. 1

            Having a plan before you sit down is crucial. If you sit and putter, you’ll not actually improve, you’ll do what’s easy.

            I love courses and books. I also love picking a topic to research and writing about it.

            Some of my favorite courses:

            1. 2

              I’ve actually started SICP and even bought the hard copy a couple weeks ago. I’ve read the first chapter and started the problems. I’m on 1.11 at the moment. I also started the Stanford 193P course as something a bit easier and “fun” to keep variety.

        3. 14

          One thing that I’ve applied in my career is that saying, “never be the smartest person in the room.” When things get too easy/routine, I try to switch roles. I’ve been lucky enough to work at a small company that grew very big, so I had the opportunity to work on a variety of things; backend services, desktop clients, mobile clients, embedded libraries. I was very scared every time I asked, because I felt like I was in over my head. I guess change is always a bit scary. But every time, it put some fun back into my job, and I learned a lot from working with people with entirely different skill sets and expertise.

          1. 11

            I don’t have much experience either but to me the best choice that I felt in the last year was stop worrying about how good a programmer I was and focus on how to enjoy life.

            We have one life don’t let anxieties come into play, even if you intellectually think working more should help you.

            1. 9

              This isn’t exactly what you’re asking for, but, something to consider. Someone who knows how to code reasonably well and something else are more valuable than someone who just codes. You become less interchangeable, and therefore less replaceable. There’s tons of work that people who purely code don’t want to do, but find very valuable. For me, that’s documentation. I got my current job because people love having docs, but hate writing docs. I’ve never found myself without multiple options every time I’ve ever looked for work. I know someone else who did this, but it was “be fluent In Japanese.” Japanese companies love people who are bilingual with English. It made his resume stand out.

              1. 1

                . I got my current job because people love having docs, but hate writing docs.

                Your greatest skill in my eyes is how you interact with people online as a community lead. You have a great style for it. Docs are certainly important, too. I’d have guessed they hired you for the first set of skills rather than docs, though. So, that’s a surprise for me. Did you use one to pivot into the other or what?

                1. 7

                  Thanks. It’s been a long road; I used to be a pretty major asshole to be honest.

                  My job description is 100% docs. The community stuff is just a thing I do. It’s not a part of my deliverables at all. I’ve just been commenting on the internet for a very long time; I had a five digit slashdot ID, etc etc. Writing comments on tech-oriented forums is just a part of who I am at this point.

                  1. 2

                    Wow. Double unexpected. Thanks for the details. :)

              2. 7

                Four things:

                1. People will remember you for your big projects (whether successful or not) as well as tiny projects that scratch an itch. Make room for the tiny fixes that are bothering everyone; the resulting lift in mood will energize the whole team. I once had a very senior engineer tell me my entire business trip to Paris was worth it because I made a one-line git fix to a CI system that was bothering the team out there. A cron job I wrote in an afternoon at an internship ended up dwarfing my ‘real’ project in terms of usefulness to the company and won me extra contract work after the internship ended.

                2. Pay attention to the people who are effective at ‘leaving their work at work.’ The people best able to handle the persistent, creeping stress of knowledge work are the ones who transform as soon as the workday is done. It’s helpful to see this in person, especially seeing a deeply frustrated person stand up and cheerfully go “okay! That’ll have to wait for tomorrow.” Trust that your subconscious will take care of any lingering hard problems, and learn to be okay leaving a work in progress to enjoy yourself.

                3. Having a variety of backgrounds is extremely useful for an engineering team. I studied electrical engineering in college and the resulting knowledge of probability and signal processing helped me in environments where the rest of the team had a more traditional CS background. This applies to backgrounds in fields outside engineering as well: art, history, literature, etc will give you different perspectives and abilities that you can use to your advantage. I once saw a presentation about using art critique principles to guide your code reviews. Inspiration can come from anywhere; the more viewpoints you have in your toolbelt the better.

                4. Learn about the concept of the ‘asshole filter’ (safe for work). In a nutshell, if you give people who violate your boundaries special treatment (e.g. a coworker who texts you on your vacation to fix a noncritical problem gets their problem fixed) then you are training people to violate your boundaries. You need to make sure that people who do things ‘the right way’ (in this case, waiting for when you get back or finding someone else to fix it) get priority, so that over time people you train people to respect you and your boundaries.

                1. 3

                  I once saw a presentation about using art critique principles to guide your code reviews. Inspiration can come from anywhere; the more viewpoints you have in your toolbelt the better.

                  The methodology from that talk is here: http://codecrit.com/methodology.html

                  I would change “If the code doesn’t work, we shouldn’t be reviewing it”. There is a place for code review of not-done work, of the form “this is the direction I’m starting to go in…what do you think”. This can save a lot of wasted effort.

                2. 3

                  The biggest mistake I see junior (and senior) developers make is key mashing. Slow down, understand a problem, untangle the dependent systems, and don’t just guess at what the problem is. Read the code, understand it. Read the code of the underlying systems that you’re interacting with, and understand it. Only then, make an attempt at fixing the bug.

                  Stabs in the dark are easy. They may even work around problems. But clean, correct, and easy to understand fixes require understanding.

                  1. 3

                    Another thing that helps is the willingness to dig into something you’re obsessed with even if it is deemed not super important by everyone around you. eg. if you find a library / language / project you find fun and seem to get obsessed with, that’s great, keep going at it and don’t let the existential “should i be here” or other “is everyone around me doing this too / recommending this” questions slow you down. You’ll probably get on some interesting adventures.

                    1. 3

                      Never pass up a chance to be social with your team/other coworkers. Those relationships you build can benefit you as much as your work output.

                      (This doesn’t mean you compromise your values in any way, of course. But the social element is vitally important!)

                    2. 13

                      One thing that a co-worker drilled into me about 5 years ago now was to accept that code is fundamentally communication. The code that you work on every day is not written for you, it’s not written for your boss, it’s not even written for your customer. Your customer wants a product or an experience, they don’t care about the code that comprises it.

                      Your code is written for the person who’s going to come back to it 3, 6, 9, or 36 months from now wondering why things aren’t working the way they think they should be then, and trying to understand what the mindset was right now at the moment you’re writing it.

                      This mentality should drive naming. It should drive design. It should drive documentation. It should drive even the most basic assurances about how you understand your code to function now, including some of the libraries that you consume and rely upon. That’s a fancy way of saying tests.

                      So, code isn’t just about being a sponge for technical documents, the latest frameworks, and the cool new tools. It’s about clearly communicating your present mindset for consumption by somebody else.

                      Here’s an actionable exercise: write an program — Conway’s or ENIGMA or something — and come back to it in a year.

                      1. 5

                        Recording your screen is an interesting idea. My guess is that what’s really at work is reflecting on what has been done; the screen recording/playback is just a catalyst.

                        If I recorded my screen I’d get a whole lot of… not much since I do a lot of work that doesn’t show up there. Lots of code navigation, trying to make the mental connections to piece together the parts, wouldn’t be fruitful to watch. I do, however, keep notes (both analog and digital) and the act of writing them is often enough for me.

                        Also, it’s a little distressing to see the reason for reviewing the screencasts is to write the program faster. If that’s your goal, you’re setting yourself up for disappointment.

                        (edit: hit “post” too soon thanks to unknown key combination. grrr)

                        Stories with similar links:

                        1. My Approach to Getting Dramatically Better as a Programmer via breck 1 year ago | 22 points | 5 comments
                        2. My Approach to Getting Dramatically Better as a Programmer authored by malisper 2 years ago | 22 points | 12 comments