There’s no real shortage of growth stories at Picnic. We have a successful Tech Academy program that cultivates great engineers from the ground up. In addition to this solid foundation that sets engineers up for success, many unique experiences also shape their growth at Picnic. In this post, I recount my experiences of growing from an intern to eventually leading projects and share some key learnings that I picked up along the way.
Four years ago, I joined Picnic as a summer intern with a simple goal: learn as much as I possibly can about building good software. I understand that vague goal a lot better now, though I’m still nowhere near done. Looking back, the road here was anything but a straight line. It was full of hurdles and a fair bit of discomfort. If I could sit next to my younger self and share with him the directions in which he could focus his energy, here’s what I would say, roughly in the order I figured it out.
Be a sponge
It was my first real job, and I knew very little about building software. The most common advice I heard was to “be curious and ask a lot of questions”. So I of course did, but asking was only one part of the essence of the advice. I learned just as much, if not more, from observing the ways of the people around me. With the luxury of being surrounded by very talented engineers, there was ample wisdom to pick up on “just” by paying attention to the standards they lived up to. Observing their ways made for invaluable input: their ways of writing code, reviewing others’ code, disagreeing with each other, and finding common ground with colleagues despite disagreements. These observations set me up to then ask them why they did what they did in the exact way they did it.
Finding things I didn’t readily grasp and then hammering my way through it by asking questions worked well, so I leaned into that as hard as I could. Whenever I noticed a gap in my knowledge, I deliberately picked up tasks that I knew would require that gap to be filled; a know-how of the exact things I didn’t yet understand. Each new task dragged me through a new corner of the system and helped me close these gaps, either by asking for guidance to get through it or by reversing the roles and pairing with another engineer who was closer to the problem.
While this approach had me leaning on other people, I eventually started to feel independent. I could find things out on my own, navigate the code well enough to comprehend how a system worked by myself, and figure out what an open-ended task needed without much help from others. Being a sponge had started to pay off!
You’re surrounded by new pieces of knowledge in different forms; be a sponge and absorb as much of it as possible.
The ability to independently finish tasks had me believing that being a sponge was only a phase and its objective was finally achieved!… until a colleague gave me a piece of advice that I only really understood much later: “Don’t let your independence slow you down”.
He meant to say that being able to figure something out by yourself doesn’t always mean you should. Being a sponge had worked well because it’s much faster to borrow someone else’s hard-won intuition than to build your own from the ground up. Not having realized this on multiple occasions, I’d quietly burned many hours exploring large codebases and systems on my own when a two-minute conversation would have told me exactly what I needed.
Being independent is a good thing, but it shouldn’t stop you from just asking for help when help is available.
The sponge phase never really ends by the way; the volume of things to absorb keeps increasing as you grow. In retrospect, being a sponge and accumulating knowledge turned out to be only half the job. The other half was getting them back out of my head and into someone else’s, and there I was surprisingly bad.
Articulation and Abstraction
One moment made this obvious. I was in a meeting with another colleague from my team and a few business stakeholders. At some point, I tried explaining something to the stakeholders. But I could see that it simply wasn’t landing as I had expected and only confused them further. Then my colleague said what sounded to me like the exact same thing, and this time, everyone got it!
I’m exaggerating a little, of course. She wasn’t really saying the same thing. She was saying it with the right words, in the right order, leaving out the parts that didn’t matter to that particular audience. Some of the stakeholders are quite tech-savvy and can understand the technicalities of a system, and others just prefer the overall shape of an idea. She understood which audience was which and managed to tailor her response accordingly. Being a sponge had given me plenty of knowledge that helped me reason about our systems, but I couldn’t reliably move the ideas from my head into someone else’s, and that gap was suddenly very visible.
This realization also highlighted a differentiating factor of the people who I felt had taught me best. They weren’t always the ones who knew the most off the top of their head. They were the ones who could phrase what they knew in simplistic terms and tailor it to my understanding, so that it slotted neatly into my existing way of thinking. Articulation, it turned out, was a skill of its own, and one I’d been undervaluing.
The ability to articulate your thoughts well is an invaluable skill that allows you to harness your accumulated knowledge and communicate your thought process to others.
As I was trying to improve on this front, a colleague would often advise me to avoid “complicating things”. My brain would struggle to accept this advice and promptly remind me that our systems really are complex. Eventually, however, I realized that he wasn’t denying the complexity; he was instead pointing at the abstractions that I was missing. Simplified mental models that would allow me to easily hold complex systems in my head while also helping me articulate elegant explanations to share with others.
I started looking for opportunities to build these abstract mental models and to practice articulating my thoughts, and a lot of it was unglamorous. As I often helped onboard new engineers to my team, through trial-and-error, I gradually grasped how much detail needed to be omitted to effectively explain new concepts from the ground up. To pursue this further, I later started teaching a course in Picnic’s Tech Academy. Preparing the coursework and teaching a broad and diverse audience across many sessions forced me to explain the same concepts in simpler and simpler ways until they could be understood with very little effort. I observed another shape to this gap in my day-to-day: thinking on my feet in architectural discussions, putting words to a thought as fast as it occurred, and grappling with other engineers’ questions in real time showcased yet another aspect of the same gap.
The abstractions didn’t just help me simplify my understanding; they also helped me think faster and articulate my thoughts better. Words became a useful tool for understanding how someone else framed their ideas and for getting my own half-formed thoughts out where they could be reasoned about. None of that happened overnight, and I needed ample room to be bad at it first before I became better, which took patience from the people around me.
Abstractions allow you to comprehend complex systems, form simple, elegant explanations to share with others, and grasp others’ thought processes better. Good abstractions make way for better articulation and consequently better collaboration.
Be the stupidest person in the room
Reflecting on the process of being a sponge and building the abstraction and articulation abilities, there was an interesting common theme: the eureka! moments had come from situations where I happened to be the least knowledgeable person in the group. Once I caught on to this pattern, I stopped waiting for it to happen and started arranging it on purpose.
As I felt completely out of touch with operational skills, I volunteered for many of the on-call shifts. Although solving issues in production was challenging, the mental models I built up helped me get better at it faster than I’d expected. I also volunteered for projects where I genuinely had no clue about where I’d begin. One of them was building an application that would be packaged and deployed onto Windows-based picking stations in our hybrid fulfillment centers. This was a world away from the Java-based, cloud-run, Linux-built, fancy-CI/CD assisted setup I was used to. But it opened doors to a whole side of engineering I’d have never otherwise seen: building and deploying on-prem software to machines on a warehouse floor. In similar ways, I kept trying to stretch my scope a little further than what felt comfortable. The practice that kept working well was to put myself in situations that demanded growth rather than to wait for growth to be offered to me.
Instead of waiting for “organic” growth or being offered growth opportunities, actively put yourself in situations that demand growth. A workplace like Picnic that encourages this will turn out to be a boost to your career.
There is, however, a catch to doing this well. I’d kept at it long enough and built large amounts of business and technical context in my head. As a result, it had become harder to find rooms where I was the stupidest person. This momentarily felt like success, but it was also a signal that I’d started to plateau in some ways. I had a choice to make: build even deeper specialized knowledge about the systems and the part of the business I’d been working on, or go and find the next set of rooms where I’d be out of my depth again.
I then made as big of a lateral move as I could inside Picnic: from the Warehouse Systems domain to the Consumer domain. As though with a flick of a wrist, I was clueless again! Everything was different: the problems Picnic was trying to solve, the scale of a consumer-facing product, and the focus of the business as well. I had built a good understanding of how Picnic’s fulfillment wing gets groceries to families’ doors, and now I had to learn how Picnic builds the polished and personalized experience that makes someone want to open our app and place an order in the first place. Back to being a sponge and building a whole new set of abstractions in my head.
To me, you are a senior
Continuously chasing rooms where I was the least capable person had an unintended side effect: whilst being the stupidest person in rooms for a few years had given me a fast-tracked growth path, it had also given me an unshakable feeling that I was inferior to everyone else. Despite this arguably being a self-induced “illusion”, this line of overthinking became a real source of impostor syndrome and at times made me feel like I was crawling through quicksand, failing to make any real progress; because obviously, how else could I still be the stupidest person in these rooms!?
I’d always considered becoming a “senior” engineer a significant milestone. However, reaching this milestone didn’t come with the grand feeling that I’d expected. I didn’t suddenly feel like I knew a lot about building software. If anything, I felt the opposite. I had a much clearer view of how much I still didn’t know (The Dunning-Kruger effect is real), and this didn’t help with the feeling of being an impostor.
Early on, a mentor had shared an important lesson: he challenged me to give feedback to my seniors and my manager. When I’d reluctantly explained that I was still a junior engineer and didn’t understand enough to do what he suggested, he said: “To me, you are a senior”. It didn’t exactly sound like praise, but his intentions are quite clear in hindsight. He was pushing me to stop treating my juniority as a fact about who I was, and to start treating a lack of ability as what it actually was: a signal, a shiny piece of feedback on a silver platter, conveniently pointing at the thing I should practice and improve upon next. In clear hindsight again, that is exactly what my role models would do when they identified where they were lacking.
People in various fields experience some form of an inferiority complex; it can take a long time for scattered positive feedback to accumulate into an indisputable fact that fully dampens this feeling, but many find a way out of it. One of the hard realizations that helped me on this journey was that it was completely irrelevant how inferior I actually was. Dwelling on this feeling was not only unproductive, but it also held me back longer by taking away my time and energy from being spent on the necessary learning processes.
Do not allow your juniority, inferiority, or any other gap to define and restrict you. These thoughts can take up considerable space in your head and slow down your progress. Avoid paying heed to these thoughts and stay focused on making progress; it’s what you’d have to do anyway to eventually grow out of this feeling.
Our loyalties are to the system
Among other things, the responsibilities of engineers in a project include facilitating technical, architectural, and design decisions that guide the execution of the project. This decision-making often boils down to answering why we should build things one way instead of another. This was a common theme across projects of all sizes: smaller projects could ask why a column should exist in one database table rather than another, and larger projects could ask why reserving our warehouses’ stock should be an idempotent operation. Answering such questions required zooming out a little bit and asking myself a slightly bigger question: how does this decision relate to the other adjacent decisions?
Zooming out from one question to a bigger one brought along some discomfort with it. I was pushed to see a bigger picture and consider more moving parts instead of “just” trying to answer a simple question. While it was tempting to treat this additional cognitive work as “overhead” that needed to be optimized away, time has proven that this exercise of consciously looking for a bit more context, considering the prevalent circumstances, and making explicit tradeoffs is more of an investment.
With one of the projects, this habit of questioning and zooming out had led the engineers to challenge the feature they set out to build in the first place. The line of questioning started out asking “Why is this the correct way to build this feature?” and slowly grew: how would this feature fulfil that customer need? Why is the current goal to fulfil that customer need? Which customer need do we want to fulfil next? How does today’s feature impact the way we will fulfil the new customer needs a year from now? Why not then build this other feature that would act as a foundation for multiple future features?
Instead of optimizing for one slice of today’s problems that the initial task focused on, the questions first tried to consider more of today’s problems, and then the problems of the future as well. This broader consideration of today’s work along with the future plans hinted at the possibility of a better holistic product that could be relevant for longer. Probing for the right questions and subsequently the right answers had ultimately led us to build a more future-proof system that today allows both Picnic and its customers to create recipes in similar ways.
Confront decisions and assumptions with “why?” every step of the way. The answers will often lead you to consider the overarching goals of not just the project, but the long-term goals of the team, the product, and the organization. In the long term, our loyalties are towards building a system that stands the test of time: is easy to extend and build upon, can adapt to future business directions, and offers a great customer experience for decades.
The environment compounds the growth
Looking back on my journey so far, the common thread across all stages is that my professional growth wasn’t solely a result of my work. My contribution to this journey was to stay curious, identify the gaps in my skills, proactively work on closing them, and keep pushing my comfort zone when possible. Others’ contributions also compounded this: my colleagues and mentors who trusted me with interesting and challenging problems, showed a great deal of patience while I learned to be good at tackling those problems, shared honest feedback along the way, imparted valuable lessons, and were invested in my growth.
Although I feel there is still a long way to go to realize my initial goal of learning to build good software, I think a certain side-mission is a valuable addition. I’ve developed a deep appreciation for the people who help others grow and realize their full potential, and that is an important skill that has its own nuances. Going forward, I also aim to cultivate the skill of effectively coaching young, budding engineers and help them grow as my peers helped me.
In addition to peers, organizational aspects impact the growth of its engineers in a significant way. An organization’s working culture, the problems it aims to solve, and the general approach to finding solutions together make for strong stimuli. An organization like Picnic dares to tackle big problems, is ready to make mistakes along the way, and then iterates and adapts fast. It naturally welcomes the attitude that keeps people curious and pushes them to slightly stretch their own comfort zones. If a room that has ample challenges and opportunities excites you, come and join us at Picnic! There’s a lot left to build, and plenty of room to grow while at it.
Intern to leading projects was originally published in Picnic Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.
Parinith Iyer
