Yesterday we kicked off a new „event“ format @s2engineers
Every 2 weeks I talk with one developer about „what being a developer really means“
For more transparency and to normalize things, especially for early career developers.06:44 AM - 03 Sep 2021
“What being a developer really means” - that’s the name of a new internal series initiated by my colleague Feli. When I spoke to her after the session, she told me that she was so surprised to see how many people joined. I think she hit a nerve.
Throughout the session, everyone listened intently to what Raffaele had to say and it to me it seemed like everyone could relate 100% so it would be a shame not to share it with the world.
Learn how to learn and find a good mentor
The first question Feli asked was about what he wished he'd known when he was a junior dev. One of the first and most important things for him was to "learn how to learn". There are many learning techniques and in the beginning it's not easy to figure out which one(s) work best for you. It's always good to have someone by your side to support you, too. Finding a good mentor is essential for Raffaele. He also mentioned that he used to avoid reading code, simply because he didn't understand it. Avoidance is never the best approach but he eventually managed to face these challenges head on.
Top Google Searches
Everybody knows the struggle: no matter how many times you look that one thing up, you instantly forget it after and find yourself searching for the same thing over and over again. For Raffaele, it's, among others, git commands. There is this omnipresent fear of destroying things and double checking definitely helps. Who can relate? In general, he says that googling or doing research is part of the job of a developer and he remembers that back then it wasn't as easy as today to simple type something and get a result within seconds. There's no shame in googling every day. Over time, he also learned that it actually depends on how you look something up. What he does is to search for topics rather than specific questions.
Pair Programming - Trust the process
In the beginning, pair programming was hard for Raffaele because he wasn't structured. At some point he got lucky and found someone who helped him and told him to trust the process. Doing courses, watching videos and reading theory about it as well as practicing with nice colleagues helped him to get into it. Nowadays, he does pair programming every day and he thinks that it's essential. One thing he also learned was that you don't always have to do it with someone who is more experienced or an expert on that topic but rather do it with people who don't know much about it because they are the ones who challenge you the most and ask the right questions.
Have a little patience, or just rage
One of Feli's questions was whether there is something that really makes Raffaele angry. He said that he doesn't really have a lot of patience when the computer isn't fast enough (who stays calm in those moments anyway?).
Believe in yourself
Finally, Raffaele was asked about his advice for early career developers. Again, he repeated, having a mentor is a game changer and super important. Be your own cheerleader, believe in yourself and don't let the pressure of achieving something super big or a certain title fast get to you. We live in a performance driven world and it's important to remember that we all started out as beginners and nobody's perfect.
Thanks Feli and Raffaele for this great first session. You showed that, in the end, a lot of people do have the same struggles and meet the same challenges in their work - no matter what level.
Top comments (8)
Thanks for sharing experiences! It was great reading to them.
There's a free course in coursera about "learn how to learn". I'm hundred percent reccommend it
Be obsessive about stomping out bugs from your code.
I woudln't say obsessive, but I get your point. To be honest, bugfixing become one of my favorite part when it comes to programming :)
Yeah what I mean is that most novices write their code, run it once and call it a day..
An experienced developer is a lot more paranoid about that and uses asserts, traces, pre-emptive debugging and unit tests to ensure their code works before calling it a day.
I would often consider it a challenge to be able to submit code that testers could not break. It was very hard to do because we had really good testers.
Thanks for sharing , same problem i was facing for finding a good mentor and its really essential for junior dev.
Did you found some in the end?
Yeah okay but how to "find a good mentor"? It's easy to say "find a good mentor" but it doesn't have any meaning.