I Still Want To Be a Programmer

This week was different because I started to see the first programming things in the Academy. It wasn’t just the code problems, I began to notice the workflow and characteristics that is recommended have to work in a development team.

Fail fast and learn

It’s hard to admit that you make mistakes, yes it is. I had the mindset that your intelligence is equivalent to the mistakes you make, but this is not right. Our skills are equivalent to what we learn and making mistakes is one of the best ways to learn. Errors are not bad, the unacceptable thing is not to gain experience about it because it means you didn’t get it.

So fail fast and learn. I enrolled in this phrase “It is better to present 80% of your project than to do it a year later at 100%”. You can present something functional but not complete and improve it during that time with the feedback that all this entails than lengthening the time to deliver something 100% (Eventually, you will notice that it was not 100%).

Take risks because it’s a way to learn quickly.

You’re not a genius but not a fool either

Being a small fish will be better than being a big fish. In my university I was the best programmer in my class (no ego) and it was very comfortable to be. I had no problem with the class, the teacher sometimes asks me for help, etc. What happened? I didn’t learn enough. Now I’m enrolling in a microservice project and the Academy, I’m uncomfortable in both because I know that I don’t have the knowledge of the other developers. Am I scary? Yes. Am I learning too much? Absolutely. It doesn’t matter to know less than the rest, the important thing is to take all that you don’t know and grow as a developer and as a person.

I’ve learned not to appear to be a genius because I am not, this week I had a problem with my code in google jam (The class name would be “Solution”). I tried to solve it for 2 hours and I changed some code because I believed it was wrong with my logic. I asked in slack for a hand, and indeed it was only the class name. “How long will you drive around lost before you stop and ask for directions?”.

Collaborative activity

Collaborative activity is equal to a successful software. In the code challenge of this week all Academies were working together for a successful project, I was not working for them, I was working with them and we were a team. I noticed that each one of us was working to make the whole project work and we were not working to obtain individual credit.

In the end the best of each of us came together to solve a programming challenge and it resulted in strengthening our weak skills.

Something I learned and still have in my mind is “We are programmers because we like to program, not because we like java”. This week I had the opportunity to practice in other programming languages and it was awesome. At the beginning was hard but eventually was fun and I understood that I can handle any language.

Don’t victimize yourself

This week I felt like a victim of things outside of me. My computer was crashing, my internet was slow, and I was feeling sick. The truth is that I was a victim, a victim of all this.

Being a victim is not bad, victimizing yourself it is. I learned not to victimize myself, and although I had these problems I found the solution of how to handle this whole environment. If I had victimized myself I would say “I can not do anything for my internet”, “Do not assign me tasks because my computer does not work” I would not have gotten anywhere with this.

Perception

I learned about perception and empathy.

Perception is the way we see things, our mind is so complicated that assuming that our perception or the way we see things is the reality for everyone. When the truth is that everyone has their reality, so it is very difficult to assume that something is blue, when the perception of the rest is other colors.

That is why empathy is an important capacity in each of us. When you learn to put yourself in the shoes of others, your vision of the world changes. This week, I was empathetic with some of my partners who have had less experience in topics like algorithms or git. I helped in the best way possible, putting myself in their shoes to continue with the project because for example, 3 months ago I didn’t know anything about git and I know that acquiring the knowledge is hard so that someone can tell you that is not difficult and you feel worse.

Conclusion

Being successful as a software engineer means not just being successful with your code base, it also means how to deal with people. Take risks and say “Let’s try this”. Maybe this fails and you learn or do something extraordinary from an idea that you did not want to do.