Ryan O'Shea

You are here to contribute.

This is the instruction that I have used to guide my decisions and actions over the last year. It could have come in different guises like “adding value” or “making a difference,” but contributing is what has stuck with me.

With a contribution, an author lets go of their work so that it comes together with something larger. The verb contribute comes from Latin, contribuō (con (together) + tribuō (to share or grant s/t, to give up s/t)). The Latin verb tribuō gives us “tribe” and “tribute” in English. I can imagine that one critical success factor for a tribe’s growth or survival are its members’ ability to share or give up some of their labour or possessions that are aligned with the goals of the tribe. Metal workers need food and might not have time or skills to forage or farm. In the same way engineers don’t often close high value B2B contracts.

This article explores some of the themes that became important to me as an entry level software engineer, and how giving attention to these themes help me become a more conscious and effective contributor.

Disclaimer: these opinions are my own and are not intended to communicate any shared message or values.

Second disclaimer: this article won’t list my interpretations of Jira or React documentation as a how-to guide for other entry level devs. dev.to is packed full of excellent articles where new devs can showcase that communication skill.

Customers and Users

I learned that there are users, and there are customers. Customers can be users who pay and keep the lights on, but can also be large corporate entities that get tangible benefits from maintaining recurring relationships an employer’s bank account.

Delivering what people will pay for is essential for the growth and survival of most for profit organisations. Finding out what to create or improve seems a most important MIT. Get that wrong or enter the product death cycle. No one ever wants that.

Users and customers matter, but user and customer problems matter to different degrees.

Alignment 1

How critical to the success of the company is this ticket?

Find out before going all in on something that could just be an unnecessary sacrifice of hours and effort.

Learning by Doing, Tools, and Writing Code

“I’m here to learn”, I told myself and colleagues in my first days. So, I became someone who was here to learn how to contribute effectively. This article is part of that development, as is my reading list and engineering notes, my daily reflection before the stand up, monitoring self talk and how I think about my work, and speak about it with others.

I also learned that working on a code base and observing what happens before and after any changes can inform my understanding of what is possible and not just what works. This partnership between existing code and my changes surprised and excited me: this Typescript application could also teach me about Typescript.

This matters because I am balancing the excitement of making something with the weight of code reviews, coding standards, setting and resetting statuses, documenting my process and why changes are made, using the right communication tool or language feature in the right way and the right time, updating and checking off task lists, creating tickets according to spec, and remembering to turn on or off my mic in zoom calls.

That balancing act could become a battleground, but far better to understand it as another partnership where my impulse to create is informed by the tools, and produces an coherent set of commits with code that my colleagues can read and reason through, and give clear and concise comments to improve my contribution.

Alignment 2

What and how to learn?

Find out how each tool is used by the team work to deliver code that solves our business problems, and then how to develop the knowledge and skills so that my contributions are always improving incrementally.

Company and Colleagues

“But what are the business problems?” I asked myself. Obviously, getting people to pay the company, which means figuring out what they really need, building that thing in the right way, and then letting them know. Which also implies finding the people and making sure all that happens before the money runs out or some other group comes along with a better offer.

My buy-in to HoloBuilder was there as soon as head of engineering approached me in spring 2022. The product and industry aligns with my long term interest in construction and buildings, and generally managing processes.

Momentum and urgency matter to me. Workplaces where stuff gets blocked or gets done slowly kills the will to excel. I hate “phoning it in” or being around that attitude. Business is always precarious and when the shutters come down we often aren’t left with much. I was pleased to find urgency and momentum, and enjoyed taking opportunities to maintain or create that vibe by working together with my colleagues in a consequential manner.

But most rewarding challenge has been figuring out when and how to ask for help. I was a teacher and manager for 15 years before I came into software engineering. I was usually the one who fixed problems and helped others to figure out how to fix their problems without me. Looking for and receiving help doesn’t sit easily with me. But insights gleaned from valuing urgency and momentum to helped me to learn when and how to ask. Easily, the most valuable takeaway from the last 12 months.

Alignment 3

How should the business needs inform my relationship with my colleagues?

Understand how blocks and a lack of urgency can slow down the velocity of a team and delay when users can give feedback on the app.

Everything Else

When I walked the walk, I discovered again that the map still ain’t the territory. Before I started working at HoloBuilder hiring managers would tell me again and again that they were looking for someone with experience. I had a good idea how an agile, product centred, software company worked for an outsider whose only contact had been going to a ton of meet ups, reading blogs and listening to podcasts, and talking to engineers and founders.

And honestly, until now, and with complete humility, nothing that I have heard in the last year seen has struck me in the same way as my first steps into programming back in 2017. But what has impressed me are my colleagues’ skills, and the amount of effort I have had to consistently put in to become that effective contributor. Being a software engineer is a great job, but it isn’t easy.

This stress and anxiety took me back years to when I first started teaching. Back then I would leave little to chance. Consistent preparation, reflecting on my performance, revising lessons, helped to calm my nerves and with time I began to accept the quality of my work as a teacher. Remembering this older lesson helped me to let go of that early anxiety and settle into my role as a software engineer.

Alignment 4

When has there been similar challenge in my life and what can I learn from that now?

Dude, you like telling stories. So, tell yourself a story about your past that will help you to get through this challenge and boss it on the other side.

Final Thoughts

• Read error messages. Read them carefully. And follow them. They will have the answer you are looking for.
• Be vary about going off piste with git. Stick to what you know works. That new technique which promises a shortcut might cost you dev hours to figure out how to fix something really annoying.
• Enjoy releasing. You’ve deployed to test environments, the code has been tested, you have follow the release steps. It’s going to fine :-)

My colleagues across HoloBuilder and Faro have been supportive since before I started. Having colleagues that are skilled engineers and are open, patient but committed to producing high quality software meant I had clear objective but room to learn from mistakes. I would like to thank them for making those choices and creating a healthy and ambitious working environment.