What I learned during my time at Talkdesk?

Talkdesk certainly was an amazing school for me, my background was based on consultancy context, which was also a school but for a different set of skills. When I joined, I immediately realized that I was just another fish in a big ocean of sharks and whales. Which was great, I knew this was the kind of perfect environment I wanted to be in if I wanted to improve my technical and soft skills as a developer.

So, after my big journey, I decided to gather a few things I learned, and I believe that help me be a better person and developer.

As a person

• We need to deal with our own ego, manage it in order to not override anyone’s voice — we are not the highest brain of any place. We are no better than anyone even if you have the highest role. We need to be humble to listen to others and to not disapprove or discard any idea upfront without actually think about it or at least giving a constructive feedback on why the idea wouldn’t be so good (also the way how it’s done it’s important)
• Don’t be afraid to use your resources — Use your resources, talk with whoever you need with no shame nor embarrassment. Everyone is a resource to someone at some point, even yourself.
• Changes are inevitable — we actually need to deal with the emotions when changes happen, we need to embrace them regardless of your position and feelings.
• People just leave and that’s normal — nowadays there is a huge rotation of people in projects and companies, that’s already normalized for the upper management, so we should accept it. It’s not easy, I know, but… it happens.
• Proactivity takes you further — I hate when people say “nobody is paying me for this”, I mean, I understand, but it depends on the circumstances. You always need to do more than your current responsibilities if you want a deserved promotion. You are promoted because you already have shown to your supervisor that you are capable of doing the tasks required for the next level.
• Support is one of the best tools you can have/give inside a team, it always makes things better. If people look for you in order to ask for help, it’s a sign of trust, don’t neglect it.
• Unfairness exists everywhere, if there’s something that is making you feel distressing or uncomfortable consistently, reach out to your manager or someone else above with power to change your situation. You are the only one responsible for your own happiness, so, once again, use your tools in your benefit. A safe environment helps you grow.
• Working hard it’s not working more hours, be focused, be efficient.
• Every person has their own pace — I am a very accelerated person, so it’s hard to me to deal with people way slower than me. But I had to accept the fact that people can also bring results on their own time and that doesn’t predict them as bad workers (internal fight over here!! )

As a developer

• Your work is mostly around people, not software. Reviews, documentation, communication, testing, managing work relationships, product delivery to clients. IT’S ALL ABOUT PEOPLE
• Software engineering it’s not only about coding. Actually, you mostly code for humans, not for machines. If you write your whole code in just one file, the system will understand regardless, but humans won’t.
• Being a senior is not just about experience, but it’s a mature mindset of how to deal with people, conflicts and solutions.
• People already expect you to do what you do, you were hired to perform this role. So, if you are super proud of achieving a complex task, of course that gives you visibility inside your team/department, but still it’s your job. Keep it to yourself as a learning experience, because this kind of tough task BENEFITS YOU MORE as an internal endorsement experience than anything else. Don’t expect this to be the ultimate reason for your promotion (this is just advice to manage expectations).
• Your developments can be done by anyone else. There is code review, testing and standards in a company. Usually you code following what already exists and if not, someone will tell you and teach you how to. Everyone with the capacity of learning will do whatever you do, keep that in mind.
• Discover and show your distinguish trait in a team. That brings uniqueness and greater value to your contributions as an employee. It’s mostly likely that you will be proactive in the things you know you are good. Like I said before, proactivity takes you further.
• Look for help, you can try on your own, but don’t take too long. If there’s any task that you can’t progress, look for help! You are working to achieve results as a team, not as an individual. Any working environment that only points out things you don’t do with no plan to help you, it’s an environment that needs to be fixed.
• Don’t neglect agile, it gives you crucial data to improve your team results and workflow. I had this idea before that agile was too flexible in a way that I didn’t understand how could that help a team. After checking those charts and discuss with the team those numbers every two weeks, slowly started to make more sense about their true value. We used it a lot to take actions and improve our speed in delivery. We actually did it, it was working. All those sessions, just to look at our data, gave us a quantitative overview of our performance, and therefore we could actually see our improvements. It was satisfying. A small note thought, it should NEVER be used to point out mistakes to individuals, this should ALWAYS be used like a tool to improve the team as a whole. Of course, there will be a time when someone’s name will come up, but that should only be done with the purpose of being constructive and helpful for everyone.
• Your code will always be legacy — you write the code in the present but after merging it, it will turn instantly into legacy.
• The code you do it’s not yours, it belongs to the company — this was one of the first things I heard, and I’ve stuck with it since then.
• Everything you do it’s prone to change, to be deleted or just not even being used — this is hard to accept sometimes. We invest too much time writing and developing a huge feature that turns out to not be so great or needed by our clients, and therefore is descoped. Or writing 100 lines of beautiful code to fix a problem and someone comes and says “you can make it simpler”/ “you don’t need these all changes” and you will need to accept it. I remember writing an app for 1 month and then being dismissed because afterwards we would use a different approach. I know this hits your pride, I feel you sis, to ease our feelings when this happens it’s good to have in mind the previous point — the code belongs to the company, it’s not yours.
• Document and update your documentation often, but not too much. It’s super important to document your steps, meeting notes, the rationale behind some implementation. You need to write the facts for your legacy code/systems. Although, this may sound contradictory, it’s also important to not write redundant documents. There is a problem about documenting everything and not following a structure known by everyone. We end up having the information spread all over the place and probably duplicated. If that happens, no one will know where to find the document they want not even have the will to change it, creating a new one will always be easier. This information needs to be centralized and work as a knowledge base to developers and product team.

I really hope this brings value to you, share your findings in the comments section below 🙏