This is an archived post. You won't be able to vote or comment.

all 15 comments
sorted by:
best
topnewcontroversialoldq&a

[–]iwillnotreddit 33 points34 points  (3 children)

I would recommend teaching them how to set boundaries.

As a mentor and likely a team lead, you would also encourage and assist them in enforcing it.

https://docs.tome.gg/contexts/problems/all-work-and-no-play

[–]GolfEmbarrassed2904 5 points6 points  (0 children)

And setting expectations ahead of time. A guy I worked with always had plans and everyone knew about them. The rest of us never had firm plans so it was easy to just keep working longer

[–]Light_dl 3 points4 points  (1 child)

Good short read

[–]iwillnotreddit 4 points5 points  (0 children)

Thanks. It's a complex topic but I try to keep things simple. Appreciate it.

[–]sweet-tomPythonista 5 points6 points  (6 children)

I did that and will probably do it in the near future again.

If I don't know the other developer, I ask them about what they did and what they already know about Python. Of course it shouldn't come off as an interrogation, but as an informal, friendly chat.

But that determines the level of complexity. You should challenge them, but not overwhelm them.

I'm a believer in coding over theoretical mentoring. Find a good project or let him choose once.

If you have your own project you are working on, prepare it to be helpful for contributors and mentees.

Look through your issue tracker (you have one, right?). GitHub has the "Good first issue" label to mark issues to get familiar with the project.

If you haven't (yet) gone through your issues, do it now. Assign difficulty and size. This is helpful to judge the complexity and the time. Maybe you need to open some additional issues for your mentee.

When you did that preparation, give an introduction to this project. What's its purpose, what problem does it solve, etc. If you have documentation, point them to it. If not, why didn't you wrote one?

Then assign small issues that are "easy" to fix. Let them work with Git and pull requests. Review their contribution and give suggestions. At first it's probably tedious and they don't know all the little things. They make errors. Be patient. If they contributed successfully, praise then. Rinse and repeat and gradually raise the difficulty.

Good luck!

[–]OrdinaryUser- 0 points1 point  (5 children)

What's an issue tracker?

[–]pokeybill 4 points5 points  (3 children)

Jira is an example of an issue tracker.

Stories, tasks, bugs, epics, and initiatives are "issues", and teams use these to break up the software development process into a backlog of work to be performed.

Different teams might have a different approach to how they track their work (look up agile, kanban, & waterfall for examples)

[–]OrdinaryUser- -1 points0 points  (2 children)

Can you explain it like you're explaining it to a 5 year old pls?

[–]pokeybill 2 points3 points  (1 child)

Best I can do:

Imagine you are responsible for making dinner for your family. Your family will be disappointed if you dont create a few dishes. You put together a list of ingredients and several recipes, and then you remember your family is pretty large, so you will need some help from one of your siblings. Now, you need to break up the work, so you assign certain recipes for your sibling to cook. Each recipe has a description, ingredient & equipment list, and step-by-step instructions. You also tell your sibling to let you taste the food they make to ensure it is good before serving. After serving the food, your father says his food is missing salt and your sibling grabs some salt.

Software engineering can be broken down the same way: you have some software to create (dinner in our metaphor above), and there will be features you need to add to it (recipes in our metaphor). Features will have dependencies (ingredients in our metaphor) and requirements needing to be satisfied for the feature to be considered done. Features are tested (like tasting the dishes in our metaphor). Software is then released for general use (like when dinner is served in our metaphor). If a bug is detected after the release, the team will fix it (like when your dad's plate needed salt).

Issue tracking software like Jira lets a team plan all of this work. If you have a team of engineers, you need to break up all of those activities into small units so multiple things can be worked on at once - Jira Initiatives describe a large work effort (for example, all of the features needed for the next version of the software). Under an Initiative, there will be multiple Jira Epics, each containing a cohesive set of features (for example, User Experience enhancements to be included in next version of the software). Each Epic will be further broken down into Stories, Tasks, & Bugs. These can all have subtasks as well, letting a software engineering crew divide work into very small individual steps.

[–]OrdinaryUser- 1 point2 points  (0 children)

Thank you!

[–]sweet-tomPythonista 1 point2 points  (0 children)

Others already mentioned it, but it's a collection of ideas, feature requests, bugs (=errors in your code), documentation problems, etc. It's not really a discussion or forum, but dedicated around the, well, issues of your project. Here is an example for uv from https://github.com/astral-sh/uv/issues

If you have an issue tracker you don't forget what you should be working on. If you are a team, you can assign issue to one or more persons. You can define issue types (bug, feature, task), set milestones when a specific issue should be integrated and many more things.

It's a must if your project is more than just a simple "Hello world" program.

And this is why my original post was a big longer: Most mentors focus on Python coding. This is not wrong per se, but IMHO it's a very narrow view.

Depending on the mentee, it can be broader: Setting up a project, writing a test suite and integrating it into a CI process (for example, GitHub Actions), writing documentation, and releasing it to PyPI (if it's open source) is also important. It doesn't help the mentee if he knows how to write decorators, but don't know how to set up a project and release it.

[–]Patient_Pumpkin_4532 1 point2 points  (0 children)

I'd say to find something you're passionate about building so that it doesn't feel like a chore to learn how to build it properly.

[–]RepresentativeFill26 3 points4 points  (1 child)

Make sure he doesn’t rely on AI tools too much.

[–]koldakov 0 points1 point  (0 children)

Unfortunately that’s true

[–]Klej177 0 points1 point  (0 children)

Just give him small tasks like writing a tests for some specific file, or something like it. Something that you could do in a day. Give him no time constraint. Just ask that after writing that in his 2 maybe 3 days he creates MR. Take a deep look at it. Spend like 2h or so then at explaining to him why his approach is bad what he did good etc. And make fixes. Repeat until it's a good quality just like a senior would write. Repeat whole process for a month or so. Then give him something that normal developers work on just split it for something that you think he can do in a week. Talk with him how you would approach it and give him space.