1. 22

Setup: you’ve got a fresh bootcamp grad assigned to you. Approximately 20% of their time will be spent developing general skills; you won’t be responsible for this. The other 80% they’re your assistant and will do whatever you assign them, within reason. Asking them to write documentation is okay, asking them to fetch coffee is not. Assume they’re generally motivated and will invest time in learning new topics, and that you’ll be able to sanity-check anything they do.

Some of things I’d do:

  • Write technical documentation. Given a code or feature, map out what uses it and why. “Could you make a graphviz diagram of this call graph?”
  • Research and report on code. “Profile these specs and report on why they’re slow.” “I found this weird function, could you look into when and why we added it?” “Determine if this is dead code and if this route is actually used for anything in production.”
  • Design and run experiments. “We’re not sure whether to we should use Flow or Typescript for our Node servers. Please write this microservice in both languages and report on your experiences.”
  • Write quality-of-life code that isn’t necessary but makes everybody happier. “We have a general engineering calendar. Could you write a job that imports all of our personal calendars into it?” “Please write a slack integration that automatically updates our slack status whenever we’re on vacation or onsite with a client.”

What would you do?

((My motivation for asking this is there’s an oversupply of junior devs in Chicago right now. People don’t like hiring them as engineers because they can’t just jump in and be productive (see mythical man month), so I’ve been curious if they’d be more productive (and get experience) as paraprogrammers of sorts.))

  1.  

  2. 24

    So, in some ways this reminds me of the care and feeding of interns. My philosophy on that is basically:

    • Don’t give them “opinion” projects. Things like “compare these two frameworks” are just busywork, because they generally don’t have the experience to say anything of substance that you can’t read off of a blog somewhere. Further, they probably aren’t immersed enough in the bullshit business requirements of your environment to make really good analyses.
    • Give them clear deliverables. Every project they get should have a clear GO/NO-GO completion criteria. There should be an easily-testable (automatically or manually) way of verifying that their work is done, if for no other reason than to give them immediate feedback on their progress.
    • Never put them in the critical path of a project. They aren’t paid enough to justify the stress or responsibility associated with that, and the crazy bizarre shit they may come up with will become heinous legacy code overnight.
    • Give them housecleaning tasks. Building on the above two points, doing things like making deployments easier, setting up CI, or writing isolated reports for business are all great things for them to do: useful to the team, easy to gauge progress on, and unimportant if they fuck up.
    • Be constantly asking questions about how they approach things, even if they’re doing it right. Interns (and junior engineers) need to learn, and to learn they need introspection. Introspection is easiest if somebody external is asking you to explain your thought process and give constructive pushback.

    Of course, there is another school of thought (which has its benefits) which goes:

    • Use juniors to do the hard and backbreaking work of building a company. As Stalin showed us, nobody is too underskilled to be fed to the front-lines. They don’t know how bad things are, so they’ll keep working.
    • Use a few senior devs (commisars?) to keep them pushing in the right directions and not retreating. Pay these devs well, since their job is basically to prevent the impressionistic juniors from thinking too critically about why they’re rebuilding the frontend for the third total redesign in three weeks.
    • If things get bad, start farming the juniors out to other departments to help fight fires (and there will be fires). Be wary of juniors that realize they have cross-disciplinary skills, because they can disrupt management and start requesting more money. Fire them or promote them.
    • Use your juniors to recruit from their schools so you have a continual stream of warm bodies.

    EDIT: I obviously don’t support the second operating model, but a lot of people have had success with it.

    1. 8

      Don’t give them “opinion” projects. Things like “compare these two frameworks” are just busywork, because they generally don’t have the experience to say anything of substance that you can’t read off of a blog somewhere. Further, they probably aren’t immersed enough in the bullshit business requirements of your environment to make really good analyses.

      This is the only thing here I disagree with. I think “compare these two frameworks” can be a great project, if done well. The problem with reading off blogs is that they often tend to be pretty one-sided, or worse in the honeymoon phase of a technology. The best way to learn about a tech is to field-test it outside of its easy paths. So comparing works if

      • The test is a moderately-complex specification, complicated enough that you can’t just rely on framework magic
      • The implementations are hard enough for the assistant to run into difficulties with the frameworks they can write up
      • An engineer is keeping tabs and occasionally course correcting
      • There’s some quantifiable benchmark that the engineer can run, or some additional way of testing the two examples (how hard is it to add one more feature?).
      • While the assistant writes up an experience report, the engineer should run or oversee the quantifiable benchmarks.

      One example: for a data warehousing project at work, I wrote complete ETLs and implementations for both Redshift as a data store and Postgres, and ran a set of business queries to compare runtimes. That’d be the kind of thing I’m thinking of.

      1. 4

        One example: for a data warehousing project at work, I wrote complete ETLs and implementations for both Redshift as a data store and Postgres, and ran a set of business queries to compare runtimes. That’d be the kind of thing I’m thinking of.

        That might be a reasonable task for a new graduate of a four-year college with a couple of semesters of DB-related courses under their belt, but I think you’re setting your expectations far to high for someone coming out of a bootcamp. The average bootcamp grad probably has a cursory understanding of a DB as “the place where your data is saved”, little if any direct exposure to SQL, and certainly no grasp of the underlying storage paradigms or the idea that queries have a time-complexity related to how data is modeled, stored, and queried against. It’s unlikely they’ll have ever interacted with a database without going through an ORM, honestly.

        Unless you’re going to pair with them 100% of the project, you’re throwing them into the deep end.

        1. 1

          A lot of the full-timers where I work are in a similar boat :) The database is deep magic for advanced users, or something

    2. 13

      As an aside, I never get why writing documentation is considered a good job for a junior. It took me probably about 15 years to become good at it, and I still feel I have much room for improvement. Good documentation requires not only understanding things to the deep level but also enough empathy to put yourself in your reader’s shoes and explain in a way so they understand it.

      1. 2

        I really cloudn’t agree more. This is such a hard job.

      2. 8

        I was in this situation at previous work.

        The code base we were working on was a core banking system composing of about 2 mln SLoC of PL/SQL and an additional 1 mln SLoC in Oracle Forms & Reports. No unit tests and spaghetti code in a lot of places. The development process was often described by my colleagues as ‘powdering the dead’. I was a team lead and was pushing to introduce unit testing, documentation and refactoring to improve the situation a bit. They didn’t want to give me a budget to do this with my team but they did start sending interns my way. Here is what the first one did and the others continued.

        1. I attempted testing stored procedures before using Python, so I scheduled a single day and showed him my off work project that had unit tests written in python and running against a database, measuring code coverage etc.

        2. Picked the most error prone part of the code, that everyone was afraid to touch. There were only 2 people that knew that part of the system. I took the intern to one of those guys to break the ice, let them meet each other and gave a heads up that he will have questions about that code in the following weeks.

        3. Asked him to start writing tests for that part of the code and documenting what he learns about it (plus the process itself and his internship). Told him that if he gets stuck he goes to me and if I can’t help then we (or him alone) go to the expert.

        In those 2 months he got one of the biggest spaghetti function (15k SLoC) quite well tested, uncovered bugs and even did small refactors that the expert asked for and guided. Additionally it got properly documented and I got a powerpoint presentation from him that I arranged for him to show to my upper management in person.

        The outcome was:

        1. That was the first ever internship that ended up with the student getting an additional payment bonus for how well he did (management loved his presentation).
        2. I got an OK and an initially small budget to start incorporating unit tests in normal development.
        3. The team was more eager to do testing, when they saw that it can be done by an intern with no experience with little help on one of the hardest parts of the system.
        4. The student was super happy to do something that was actually very critical for long term development (most of our development budget was being eaten up by maintenance and technical debt).

        Before getting any new intern (I had 6 after that guy) I did a meeting with my team as I learned that having an ‘off the budget’ person to help was the best way to actually fix pet peeves that experts in an area knew about but never had time to address.

        1. 8
          • Writing test cases. During initial stage of my junior developer job, i learned a lot by testing the software product my company develops. I wrote test cases which includes on how a particular feature works, how it should work etc. The requirement for this is that i need to find out whether already a document exits? whether it is up to date? or i should update the document. And i have to interact with the testing team to know how to test and other teams which my module interacts. By testing i learned whether it was working the way it is intended? how it works? etc.

          • Read code. When something doesn’t work, i was always told to read the code. Since the code base is old, it doesn’t have much document on how things work and even if it has, they will be different from what the code does. So whenever something doesn’t work, my first step would be reading the code. I also developed a habit of reading code daily, so that whenever the code compiles (it would take 20mins), i would choose some module and start reading the code. By reading code, i have found more bugs in the code that would require difficult steps for the issue to happen.

          • Document what you do. Because many times i need to solve the same/similar problem. I don’t want to waste time solving it multiple times. Documenting what issue you faced, the root cause, the fix and how much time you spent on the issue will be very useful.

          1. 7

            I’d pair program with them. Seemed to work out alright in the past.

            1. 5

              It’s been my experience that’s the fastest way to teach programming. Pairing shows the how and the why. I liken it to the master and journeyman approach to skills transfer.

            2. 4

              Keeping the codebase well tested and documented would definitely be their main task. Having them write utility scripts could be a good idea as well.

              With time you would sometimes switch positions with them. Have them write a feature and you document / test it.

              1. 3

                Other crafts have this somewhat figured out, so it doesn’t hurt to look for them for inspiration. Apprentice woodworkers were tasked initially with setup work (planing boards flat and the like), and then with easy finishing work (simple sanding tasks, say), and with progressively more challenging parts of a build from there.

                A lot of feature and bugfix work in a codebase involves a combination of “heavy lifting” and “straightforward setup & polish” work. You can productively use an assistant’s time by taking on the heavy lifting portions of feature implementation or a bug fix, and then handing it over to them to do the easy parts that get it the rest of the way towards done. At first this is going to involve you essentially spelling out how to do the easy 20% (You’re going to need to write a test in this file, called this, that tests for this in this way and fails, so that I have a regression test to check my work against. When I’ve got this passing, I will have put the elements on the page, you just need to style them to appear where they should. Here’s some links to how that is done), but you’ll quickly be able to dial that back, and eventually ease them backwards into taking on progressively more of the hard 80%. Walk them through how you approached the heavy lifting portion of each task on a whiteboard at a fairly high level, but leave them to walk through your code on their own. If you directly walk them through the codebase, they’ll take longer to develop the critical skill of reading and understanding someone else’s code.

                This avoids giving them synthetic busywork that they’re not equipped to do well (fresh bootcamp grads are not going to be able to research and report on code in a way you find useful. If you give people tasks they’re not equipped to succeed at, that’s bad for them and reflects poorly on you), lets them feel like they’re making visible, real contributions, and lets them learn from the commits they’re inheriting from you.

                Don’t give them complete vertical features or QoL projects to handle on their own. Left to their own devices, juniors will approach things in bizarre ways they aren’t equipped to recognize the shortcomings of, and without constant guidance they’re apt to internalize those approaches and turn into “10 years of 1 year of experience” programmers.

                1. 2

                  I think refactoring would be a good task, because it helps them learn the codebase and run tests / write tests, while not being on the hook for big features. Then again, the results might be very mixed, because good refactoring often requires a deep knowledge of the program architecture.

                  1. 2

                    Here’s a DevOp-ish idea… Have them research then set up an internal wiki for their and your use then have them get Jupyter notebook running. Execute first on their dev machine then on another platform (ex. Mac Desktop-> Linux VM). Now have them automate it using a change management system (ansible, chef, etc.). It’s useful and it exposes them to all sorts of things they’d need to know. Each step is important, easily checked, and the outcomes are clear.

                    1. 2

                      I need an assistant that is at least as capable as I am. Every item on your list appears to me to be an activity that will cost you more time to work with the assistant a a lower-quality result than the time required to actually do the work yourself. Or hire someone with much more capabilities and share the time between you to perform these tasks at a significantly lower overhead.

                      Or try to develop automated assistants for some of these. At least that would be more fun.

                      1. 3

                        Sounds like you should be their assistant.

                        1. 3

                          Sounds like they’re unwilling to pay for the true value of the assistance they seek.

                        2. 2

                          Every item on your list appears to me to be an activity that will cost you more time to work with the assistant a a lower-quality result than the time required to actually do the work yourself.

                          Of course. Mentoring is supposed to benefit the mentee, not the mentor. This is by design. Look at the problem OP is trying to solve:

                          My motivation for asking this is there’s an oversupply of junior devs in Chicago right now. People don’t like hiring them as engineers because they can’t just jump in and be productive (see mythical man month), so I’ve been curious if they’d be more productive (and get experience) as paraprogrammers of sorts.

                          1. 4

                            Perhaps the question should have been, “What are the best ways for junior developers to gain experience?”

                            Rather the question was, “What would you do with a programming assistant?”

                            My answer remains, I would not hire such a very junior developer to be an assistant with the activities listed in the original approach. If I actually wanted assistance with those activities I would hire someone more capable.

                            People fresh out of such boot camps are the greenest of beans. I would hire them for other activities than the ones listed if that made sense for the business. I would pay for their education as software developers if that made financial sense for the business. I would not hire them as development assistants as listed in the OP.

                            1. 3

                              Perhaps the question should have been, “What are the best ways for junior developers to gain experience?”

                              That’s not the question I’m interested in asking. It’s been asked many, many times before.

                              My answer remains, I would not hire such a very junior developer to be an assistant with the activities listed in the original approach.

                              And that’s a completely fair. I strongly disagree, but it’s still a good answer.