November 25, 2020

Starting a new job is scary. It awaits you a new company, lots of new people, a whole new culture, and especially: new things to learn. Even scarier is the fact that as a fresh graduate, you probably do not know a lot about the day-to-day business of your new company, but that’s okay. The people who hired you are aware of that and will treat you accordingly. You might do a small starter project to get familiar with the codebase. Additionally, regular pair programming sessions with a senior developer could help to build a better understanding of programming techniques and paradigms, too.

But what happens once your “onboarding phase” is over? Hopefully, you are part of an eager team and start to work on your first tasks alone. Furthermore, you start participating in discussions about application architectures. You are now part of the decision making process. This is where it gets interesting.

When I started to take part in my first bigger meetings, I got overwhelmed. Imagine a meeting with me (a 23-year-old recent graduate software engineer) and a bunch of senior employees who probably forgot more about software development than I as an individual know. I remember one meeting where I had to search for the words that were said during the meeting because I had no clue what they meant (for the curious among you: one word was “Lua”, which turned out to be a programming language!). But at that point, I thought: “How the hell am I going to catch up with these guys?“. I hate to be a silent partaker through discussions. I want to contribute!

Before someone reads this and goes: “What a toxic company this guy works for! They should have known that he has limited experience and should either talk more openly or not invite him at all!!!”: chill, keep reading.

Depending on the context, decision-making meetings can be quite simple or very complicated. A meeting to decide which color a button should have will hopefully be simpler than a meeting that discusses how to implement a horizontally scalable data pipeline. In my opinion, being part of both discussions is crucial for young engineers. Even if you don’t get everything the other participants say, there are so many things to learn from such meetings, namely:

• What language is being used? Do people speak formally or informally?
• How is an idea presented to the group? What do convincing people do (except for probably having a solid proposal) that others don’t?
• How are meetings coordinated? Who takes the initiative and moderates the meeting?
• What happens after the meeting?
• …

The questions above are just suggestions. The main point: there are so many things you could observe. Being a silent observer doesn’t mean you should do nothing. The name already gives it away: observe! You can use all these observations when it is time to present your own solution to a problem.

And now the secret weapon to be used in a meeting when you don’t get what is being said: ask questions. This sounds so simple, but yet it amazes me how often I failed to do that. Leverage your unawareness and ask why someone believes their solution is the best. Ask how that one approach is different than the other.

I know that there is always a feeling of embarrassment associated with asking questions. Sometimes I think I should already know certain things, and if I ask that question, I will sound stupid. It took me a while to just straight up ask whenever I don’t understand something (I still don’t do it sometimes for the above-mentioned reasons - I am still a work in progress, I guess 😄), but let me tell you, it’s totally worth it. You get a first-hand explanation and don’t have to spend your time researching the answer on your own after the meeting. Even if the explanation is not super clear, you still get more information that you can make use of during your own research. It might save you a lot of time!

Moreover, by asking questions you show your interest and your desire to learn. Who knows, there might someone in that meeting who also doesn’t understand something but is too shy to ask. You are doing yourself and that person a huge favor by taking a step forward.

In case you are a currently in a senior role and have a young developer in your team, just know this: that person is probably extremely eager to learn, but maybe too shy to ask questions. Sometimes, a small check-up by asking “You still with me?” can already encourage that person to say whatever is unclear to them. By the way, inexperienced colleagues also do excellent as rubber ducks, but only if you encourage them to ask questions.

There are still so many aspects to this that I want to mention, but I feel that would cause this post to explode. I might add an additional post on this at some point later. I must admit that I generalized a lot in this post, since all examples and statements are based on my personal experience. I am certain, there are already tons of young engineers that have the courage to step up and say something whenever they can’t follow the discussion anymore. Also, each team is different. Maybe yours has ways and processes to integrate young developers more easily into existing projects. If you do, feel free to either send me an e-mail or hit me up on Twitter. If you disagree with what I said, don’t even bother contacting me. Just kidding, then I would encourage you, even more, to hit me up and tell me about your expriences. At the end of the day, we all have a knowledge gaps somewhere. Help me to get rid of mine 🙂

• ← Why I created this blog and what to expect from it
• Creating a cross-platform mobile application (1) - Introduction →