An insight into what motivates, drives and inspires us — Part 2
A collection of anecdotes from the team behind LEGO.com
Back in 2020, we asked our engineering team what motivated or inspired them in their careers to get them to where they were (in an awesome engineering team at the LEGO® Group!). We have such a diverse team in terms of gender, nationality, educational background and career path just to name a few so we thought it would be interesting to hear what piece of advice helped them the most in their career. Since then we have more than tripled the size of our teams and become more integrated into the wider Digital Technology team at the LEGO Group.
So we’re running a follow up to our previous article to share more anecdotes and advice. We hope you find a message here that resonates with you and inspires you in your career or perhaps convinces you to try out a career in technology.
“Every great wizard in history has started out as nothing more than we are now: students. If they can do it why not us?” — Harry Potter and The Order of The Phoenix
Software Engineer, hailing from the misty lands of Romania. I studied Computer Science with a focus on Java, just to completely bin that and be an Application Engineer that works in React!
I am a massive Potter-head, and these books/movies have influenced the way I approach things in life quite a lot. This quote specifically is something that I refer to quite often nowadays.
When I first started working as a software developer, I was not very confident on my skills (probably being hired while still being in university made me think I wasn’t prepared). I was afraid that if I asked for help, people would judge me, and would think stuff like “Who hired this guy?”, and I avoided pair-programming like the plague, thinking that it was a test to see if I was any good.
But this cannot be further from the truth! With time, I started seeing that everyone was asking questions, sometimes about the simplest things, or senior devs straight up saying that they don’t know something that others know and asking for help. This really motivated me to come out of my shell. And it immediately made me think about this HP quote, which made feel much more confident about the way I approach things.
Once I’ve started to embrace this mentality, I’ve started to feel much better and much more confident when working. It made me more curious, more explorative. I would sometimes see tickets that I had no idea how to do, and just pick them up to learn something new either by asking people about them, or pair-programming with people with more knowledge. The world of software engineers is, fortunately, a very friendly and welcoming one. Everyone is always happy to help out and teach you stuff. That belief has been further solidified the moment I joined the LEGO group, since I was new in a completely different codebase, the moment I started asking for help, people immediately volunteered and I started feeling integrated in both my new team, and my new workplace!
To all new engineers, or devs that feel afraid or shy about asking for help, I can 100% guarantee you can cast that fear away. You won’t be judged. All you have to do is start exploring and asking questions, there is no such thing as a stupid question! Cause let’s be real, every single dev or person with a huge amount of knowledge has started from the exact same point that you did as well. If they can do it, why can’t you?
“Rake it ‘til you make it”
A career changer who studied model-making and then worked in architecture and aerospace as a CAD / CAM engineer for a decade before giving programming a go and has stuck with it since.
In an exposed brick studio in Hoxton my pairing buddy for the day uttered the words, ‘Rake it till you make it’. We were a month into our career change of becoming programmers with Ruby as the taught language and Rake as the task runner we used for testing. We were stumped with one of the daily challenges and when we ran Rake our terminals were full of red messages. A quick look around the studio told me that everyone was in the same position.
You both then start thinking about the individual tests that are failing, not the overall problem. You discuss it, write a bit of code, run rake and suddenly one of those messages are now green. You look at the next test, discuss it, write a bit more code, run rake and now you’ve got two messages that are green. This is where the term came from that you’ll chip away this imposing problem into smaller chunks till all you see is green and then you know you’ve made it.
Nearly three years later I still work with this mindset and it’s a common ethos amongst engineers. It’s completely normal to feel overwhelmed when first tackling something new, but with the help of others you see what was initially so daunting is actually made up of smaller manageable parts.
“We don’t make mistakes — we just have happy accidents.” — Bob Ross
“I am an Australian, uni dropout who just happened to find her way into tech”
I like to think I had all of this planned out, that this was the big dream, that I even had an inkling that I liked the tech industry but that’s not entirely how I ended up here.
I thought I made a mistake when I dropped out of university. At the time it just wasn’t the right place for me, so I ended up packing up and moving to London. After a string of admin jobs over the years I found myself as the office manager at a tech company looking after a team full of engineers. That’s when I realised maybe it wasn’t a mistake after all.
It blew my mind that all these people had a job where they were problem solving and no day was like the day before. I got a little curious to see if I could do it too but I kept that information to myself. If it wasn’t for an Android engineer who caught me on Codecademy and jokingly told me I could be his intern one day, it wouldn’t have planted the seed that allowed me to become the engineer I am today.
And much like the happy little accidents that lead me to this career, my day-to-day job is also full of them. I was told by a mentor of mine that the best way to get better at programming or understanding a codebase is to volunteer to fix bugs. Sure, a bug is technically a mistake, but it’s also an opportunity because it forces you to fully understand the functionality of a piece of code. It can be an opportunity to learn, or to improve the way something works, or even just simply to read code line by line.
I think trying to find the positive in any given situation makes you think about things in a different way. When I’m stuck on a problem or just feel like I’ve reached a dead end, turning mistakes into happy little accidents has been a huge motivator for me. Thanks Bob.
“You have to crack a few eggs to make an omelette”
A South London British Asian Digital Product Designer. I have a degree in computer science and through it discovered UX which I love so much more than code!
When I was younger, without realising it, I was a people pleaser. It seemed like a stress-free and easier life with minimal confrontation and often involved following the crowd. Now, trying something different and NOT following the crowd is embedded within my day to day role and it is so much more exciting. Trying something different, however, often results in challenging conversation and debate which I once steered away from but now know is the only way to achieve any form of change.
To me, cracking a few eggs doesn’t mean bulldozing your way through the opinions of others but instead being ok to try something different and getting others on board to see the bigger vision, and potential pay off.
I also think making an omelette involves not getting the recipe right every time, it might be a little runny or not quite as expected. And instead, you have to adjust and move forward, which is often hard with the pressures of failure, but those eggs are cracked now so you might as well make something yummy as any experience or outcome will always be better than never trying.
Oh, hang on a second, what if we tried this instead?
I’m an Associate Application Engineer working for the LEGO Group
Back when I was a kid and not in school, you could find me in the local games arcade. I say games arcade, it was the local TV shop as they were the only place in our small town with an arcade machine. They had one game — Super Mario Bros. I remember the first time I put in 20p and hit start. It. totally. blew. my. mind. I knew at that moment that I needed to go and do something as innovative, as colourful, as exciting and as fun. But how? It didn’t matter. I was all in, and I had to go find people who felt the same.
That attitude of not knowing the answer, but being determined to find it by asking a ton of questions has been a constant for me throughout my career. I realised pretty quickly that inspiration — the act of being open to different ideas, of sparking your imagination and searching for many answers comes only from surrounding yourself with people who expect the best from themselves and each other. People who dream big, collaborate and take incremental, small steps to actualise that dream. People who ask why and what if. People who let go of their own egos and empathise with the end user. People who are not afraid to stop and say, ‘this isn’t working, what if we try this instead’.
Fast forward a little longer that I would like to admit, and reader, I found those people here at the LEGO Group. I’ve been an associate engineer for a little over six months now, and our squad designs and builds joyful and imaginative experiences for our visitors to LEGO.com — one of which, and I still can’t help but smile when I think of this — was built to highlight our LEGO® Super Mario™ theme.
I genuinely believe that the work we do here at the LEGO Group can spark people’s imagination and make them smile. That it might inspire other young people to point at their screen and say … ‘I have to do this’ …
“Do not worry, you are doing well”
A mentor and a mentee at the LEGO Group
Software engineers tend to work well as we do not work as individuals, we work together against a project, or against a big launch or a deadline, etc. and everyone knows that it is the team playing against the game, it’s like a real life version of Dungeons and Dragons.
When I entered the LEGO Group I started as a Senior Application Engineer moving from Mid-level Engineer in my previous company to Senior Application Engineer was a big step for me. When I entered the LEGO Group I felt that I had so little time to adjust and lots of things to work on in the new project, I felt that I was overwhelmed. The more hours that I dedicated to the project, it was not enough, lots of days passed until I talked to another colleague and he helped me in organising and delegating parts of the project. In the end we divided the work into smaller tasks and everyone in the team could participate.
The project was a success and I received a lot of praise but I knew that I would not have been able to achieve it if it was not for my team.
Most of the engineers remember how difficult it was when they started, how overwhelming it felt to start in a new project, how it seems that you are not learning fast enough to keep up with your colleagues, how you tend to not say your ideas because you believe that they will be discarded and at the end you question yourself if you are good enough for the job.
It’s a slow but steady process of learning and overcoming these feelings, and what I love from software engineering is that there is always someone to help you in those moments and to tell you, “Don’t worry, you are doing well.”
“We’re all in this together” — High School Musical
I am a Lead Engineer, fairly new to the LEGO Group. I got into tech about 15 years ago almost by accident, pushed by my curiosity and need to solve puzzles. Throughout my career, I have touched many technologies, languages and frameworks (not all of which survive today); I am always learning.
I thrive from making connections, sharing my knowledge and experience with others, and generally try to make tech more accessible, often by drawing analogies with crafts, another big part of my life outside of work.
Software is about creativity and people more than code itself. That’s why the tip I give the most to new engineers and mentees is to be framework/language agnostic. As long as you can see the logical connections between the pieces of the puzzle, the syntax doesn’t matter; it can be Googled as long as you know what you’re looking for.
Mentoring is a two-way process and I always learn invaluable lessons from the people I lead. Having the opportunity to work with folks of different mindsets and backgrounds brings new perspectives. In other words: Everyone is Awesome!
“Take part in the wider developer community”
A full-stack engineer with 4 years experience in the industry with a passion for teaching kids to code and coaching engineers
I believe one of the most important contributions a modern day developer can make to our industry is investment into open source projects. They drive our workflows, enrich our software and are constantly improved upon, making them accessible to engineers both experienced and new to development.
Over my time at the LEGO Group, I’ve contributed back to multiple repositories that we use in our stack. Some examples include the GraphQL projects kindly maintained by The Guild, a band of developers with an agenda to make GraphQL more open and accessible to all. Their codegen, schema and inspector packages have been instrumental in our build pipelines to ensure all commits are typesafe and won’t cause unwanted breaking changes.
Open source contributions come in many flavours. The most obvious is a pull request; some part of the package is broken, or needs a new feature and you do that work on behalf of the community. However, this can require some knowledge of the codebase and this may be in a different language than you are used to. In these cases a second option is a valid and welcome contribution; the Issue. Telling others you have a problem will bring others who either have solved it, or are facing it themselves. There’s strength in numbers, and by being heard, a fix is more likely to come along.
Most importantly in open source contributions; be respectful and kind. Maintainers aren’t often paid for their work, and there are often other elements at play, especially in projects with larger teams. Play by their rules set out in contributions guidelines, and be constructive in criticism. You’ll be welcomed to the community this way!
We hope this collection of anecdotes help you to realise we are all on a journey in technology and the only constant is that you will continually be learning and helping your peers, either by struggling through together, mentoring those earlier on in their journey or solving problems the wider community are encountering!
