Helvetic Ruby was a great conference. I missed the time window to write about how much I enjoyed, but thankfully other people did. However, I did take notes with the intent to share my thoughts, and there is one talk in particular for which I took a lot of notes (comparatively).
Disclaimer: I really enjoyed Harriet Oughton’s presentation, and I certainly don’t want to critizise her work. Still, I couldn’t help but disagree on several points, and hopefully my opinions will enrich the conversion and bring even more support to early-career developers and more experienced ones.
TIL: ECD (the term)
First of all, I strongly encourage you to watch Harriet’s talk on Helvetic Ruby’s YouTube channel. It is titled “Postcards from an Early-Career Developer’s First Months”, and aims to “remind most of us of the common things that new developers learn, grapple with and celebrate in the first few months on the job, and for the juniors themselves, to expose how common these struggles are (and hopefully provide some pointers along the way!)”. It is a delightful talk, carefully crafted, very well written, and filled with humor; I may disagree with some of the advice given, but I cannot deny the relevance of the issues raised.
Harriet has more teaching experience than me, so I will not dare to go through her slides and add my comments in red ink in the margin like a would-be professor. Instead, I’d like to deconstruct her different points, and from there send my own snail mail – “faxes from the old devs home”, maybe.
Fax #1: you’re not the only one.
The first thing that tingled me when watching Harriet’s talk is that most of the things that she talked about, and for which she gave sound advice, are not specific to early-career developers. Maybe that was the point, since one of her stated goals was to reassure Padawans on the commonality of their difficulties. Still, everyone who joins a new company can find it difficult to set up a working environment, get familiar with the team’s workflow, or grasp the codebase, and the tips given – be patient, communicate clearly, document what you can and keep the documentation up-to-date – apply to/for developers of all level. Maybe I would have like these parts better if this had been stated upfront?
However, even though I subscribe to most of the pointers given to make onboardings easier, there was one piece of advice that I was very uncomfortable seeing, and it is: _“Use ChatGPT to explain code”. My advice for inexperienced devs is the opposite: stay away from generative AIs until you are able to distinguish the random bullshit from the relevant responses, and see obscure code as an opportunity to learn by yourselves, with or without a mentor – but a human one. No shortcuts allowed here, especially dangerous ones.
re: “Everything is new and there is a lot of it; I'm feeling lost and lose my self-confidence.”
- If you're the ECD or the newcomer: that's normal and happens to everyone. Be honest about everything you don't understand yet, and ask around for the difficulties that old-timers faced when they joined, this should boost both your ego and your acclimatization. Be patient and stay focused!
- If you're the old folk: prepare the onboarding beforehand, decide what should be learned in priority, and communicate it clearly. Be patient and help them stay focused!
Fax #2: it’s fine to have a small toolbox
Beyond ChatGPT, several of the pieces of advice given were about tooling, and encouraged leveraging lots of them, but rather blindly: installing VSCode extensions, copy-pasting Git aliases, etc.
I have issues with this approach. In fact, I would encourage people with little experience to do the opposite: focus on a small set of tools, and be confortable with not using them to their full potential at first. Yes, Git aliases are a good way to work faster – but only if you understand what they do, and how they work. And the best way to learn that is to take the long road at first, typing the full commands until you understand them well, in all their hair-pulling madness. Start simple. The same goes for all your tools. Eventually, I’ll need to know your text editor by heart, but it will be easier to get there if you learn features gradually, instead of rushing to have the badassest setup faster than your peers. Stick to the defaults. Go through the menus instead of reusing the keyboard macros of someone else. It’s like learning an instrument: if you want to be as fast a shredder as a Japanese bedroom guitarist, you must first practice slowly.
However, going slow doesn’t mean that you should not try out a lot of different things. This is my second issue with these tips: by pointing towards specific tools (VSCode, GitHub, etc.) they contribute to the creation of a monoculture. When it comes to tooling, my advice to beginners is: don’t settle on anything yet. Start with VSCode, learn its basic, then try out Vim, while your mind is still malleable and you haven’t settled on any habits. And then try out a big IDE like RubyMine. Standard-issue equipment is fine for cannon fodder, but experts have their own bespoke stuff, and to understand your own preferences, you’ll have to try different things.
Plus, I would hate to see everyone use the same tools and techniques, and I would hate even more to live in a world where a single company provides them all.
re: “I feel the need to be as well-equiped as my senior peers, and clone their setup all the time.”
- To the ECD: What you need is not to build a killer setup, it is to discover yourself and what you like and dislike in a setup, so that you can _then_ build a killer one. Change your IDE every 6 months, and refrain from customizing any until you've circled back to it. Focus on simple things, and don't let you ego drive you – it's OK not to be a power user.
- To the old folks: Don't show off too much with your Vim-fu. It's cool to keep the beginners curious and tease them with the glorious productivity gains that await them once they've mastered the basics, but don't pressure them into skipping steps, or following in _your_ footsteps.
Fax #3: it’s all about the pons anisorum, but you can cross it
I keep saying that the best thing about Ruby is its community and my dear MINASWAN. However, there is such a thing as too much kindness, and besides, it’s easy to mistake kindness for weakness when you’re obsessed with being kind enough.
In “Postcards from an ECD”, a lot of the tips for the experienced devs boil down to being kind, preparing things in advance for the ECDs, and giving generous praise. Things I one-hundred percent agree with… within reason. Of course team members should be kind to one another, but I see no reason why this should be more the case with beginners – they may be less experienced but they’re not more brittle than anyone else. The same goes for support or praise. It’s important to build trust, confidence and self-confidence; but it’s even more important to put in place the conditions for all this to build itself, and that is with clear expectations and achievable, but not negligible, goals.
What beginners need most of all, and especially if they are out of a bootcamp, is their own bridge of asses to cross. Something that poses a challenge, and will reward them with extra confidence once they’ve crossed it. This trick is to find the right bridge for each ECD. Not all programmers are driven and talented, but “alphas” and “vocationals” alike deserve to be given the right opportunities to grow, and that takes some effort, which must be tailored to the challenger, and their team; something that is not easy, but achievable, and has real value. The bridge of asses has to lead somewhere for its crossing to be worth anything! Everyone deserves kindness and praise help, but these things are means, not an end – the end is getting better by successfully doing difficult things.
re: “I feel like an idiot at best, a fraud at worst.”
- To the ECD: That's because you haven't earned your first laurels yet. Look for a difficult, but not too difficult, task in the backlog and stick with it until you've completed it well. You know you're doing well if you have to push through. Then look behind you a see how far you've already progressed.
- To the old folks: Give the ECDs actual responsibilities, but scoped to a specific field you need them to get better at. Support them as much as they need, but only from the sidelines.
Fax #4: the important work is in the tests
This last bit is more specific than the others, and may be a complete rebuttal of the final postcard in the presentation: “This is testing my code and my patience”. This part of the talk starts with “Lots of early- career developers finds testing a new and unknown frontier. As chances are, they will have been concentrating more on the basics of making working, nice-looking software when starting out, instead of protecting it against the ninety-third obscure edge case that some product manager dreamed up over the cereal that morning.” I disagree with a lot of things in this statement, so if you’ll excuse me I’m climb on my soapbox and go preaching a bit.
It may very well be that, indeed, bootcamp graduates aren’t being taught how and why they should test, but that would be a very big mistake on the bootcamp’s part. Testing is not an add-on to the writing software, it is not an extra assignment for bonus points, and it is certainly not for the benefits of product managers. Tests are what drives the design of the software. “Nice-looking” is meaningless; what matters is well-designed, and tests help tremendously the design. (And as it happens, well-designed code also looks nice – tests included.)
This is one of the others things that the Ruby community does unusually well: care for the tests. I would hate to see this crucial part of our culture go because of misguided bootcamps, if they are indeed responsible.
Tests should be cared for as much, if not more, than the rest of the code base. Therefore, the same good practices should usually be followed: don’t copy-and-paste, never write anything you don’t understand, do not over-DRY, optimize for human happiness through legibility and simplicity, etc. If TDD is not a hard requirement, do it anyway – if the others aren’t doing it, it’s them who are wrong. Granted, the tests in question may be large integration tests1, but that’s not important. What matters is to get into the habit of writing the tests first, as a way to conceptualize your understanding of the problem to solve, and drive yourself towards a sound solution.
And if you don’t know how to write tests, well, you have probably found your pons anisorum. Good for you!
re: “Tests are pointless, I want to do real work”
- To the ECD: Tests are real work. Learn to love them, and never skip them. Never. Only when you are more experienced will you know when to do without tests, but until then: write your tests, and write them first.
- To the old folks: Mentor the shit out of this. Teach the culture of testing. The test pyramid, the difference between integration and unit tests, the phases of a test, everything. Pair with the beginners on the writing of the tests, and then leave them alone, if you want, for the actual implementation.
Error: out of paper
It’s easy to give advice, especially from the comfort of my old-timer rocking chair, and I may very well have forgotten how it is to begin. I hope that my addendum, sometimes contrarian, to Harriet Oughton’s talk, will not sound too arrogant or judgmental. It is a really nice talk, and giving it required a lot more thoughts and courage than writing a blog post about it afterwards. Besides, it is an important topic, about which I do care. Hopefully, I can help a bit, too.
To conclude, there is one thing I think we should focus on, too, when talking about newcomers on the scene, especially people with very little experience and education (i.e. bootcampees), and that is: the value they can bring.
It is very common to hear calls to hire early-career developers, and injuctions to help them, invest time and energy in them, etc. But I wouldn’t be surprised if, hearing all this, companies paused before hiring these newcomers. If ECDs require so much investment, if there is so much extra training to give them, why not hire more experienced people instead? Why bother?
Harriet does touch a little bit on this at the end of her talk, and I have several arguments to give in favor of bootcampees and other beginners, but I believe that there is room for more discussions and presentation about that. Let’s try to focus more on what these youngsters can give, and less on what they need.
-
Or system tests, in Rails jargon. ↩