How to Be a Successful Software Engineer
Last week I attended the TNW Conference in Amsterdam. The day before there was another event called Young Creators Summit. As I’ve learned, Young Creators is a Dutch platform for aspiring entrepreneurs where they help young people to get better at what they do and eventually get their business off the ground.
At the summit there was a very interesting panel discussion about how to be a successful engineer. Now, as I’m a part-time student and web developer, this Is something I’ve often asked myself as well. What does it take to be a great software engineer?
Carmen Palomino and Dirkjan Bussink from GitHub and Darragh Curran from Intercom all shared their thoughts on this topic. Today, I want to share the lessons I’ve learned as well as my personal opinion on that matter. Let’s dive right in!
Know What You’re Not Doing
There’s this well-known saying which applies to all kinds of areas — including software engineering:
I know that I know nothing.
Successful engineers are good at picking the right things to work on. The things that matter. You should know what not to do and know what you don’t know. I know, confusing.
Forget about which programming language you know. You can learn another one if necessary. People will hire you for what you can be, not for what you are right now.
Dirkjan and Carmen talked about work culture at GitHub and how everything relies on solid communication. In fact, communication is one of the most important skills.
For example, most teams at GitHub are distributed across the globe. Often times, there aren’t even 2 employees in the same city. In addition to that, they use different channels to communicate like Slack, an internal support system, and of course issues and pull requests on GitHub itself.
Now, if you work remotely and use many different ways of interacting with each other, writing down what you said and agreed on is essential.
You don’t want to be known as the guy who writes bad commit messages.
Prove that you understand other people’s problems and be able to explain your thought process. Get used to the company’s workflow. When working on something new, try to make as much research as possible. You don’t want to be known as the guy who writes bad commit messages.
I liked how GitHub try to keep that spirit even when some are working in the same office. They don’t do meetings, but still have asynchronous chats via pull requests and issues. This way you don’t end up falling back into old habit patterns. All three panelists noted that newbies were surprised how easy it was for them to get used to the new workflow.
Do not Ask for Work
I learned early on when starting my first remote job that showing initiative is very important. Work doesn’t come to you automatically. If you see a problem somewhere, it’s unlikely that someone else saw it too and will tell you to fix it. This aligns with one mantra at Facebook:
Nothing at Facebook is someone else’s problem.
If you combine this with working remotely, were nobody sees you working like in a traditional office, it’s even more important that you show initiative and take action yourself. It’s your responsibility.
Take Your Time to Think
At TNW, Jason Fried, founder & CEO of Basecamp, noted that he is very worried about people being constantly stressed and working like robots. This encouraged me to ask myself: When was the last time I was simply thinking?
Fried recommends working from somewhere else or going for a long walk every day to forget about what you’re doing right now and instead think about the how’s, why’s and when’s. That’s where great ideas come from, not from working in an office from 9–5. Taking such breaks is super important for both your physical and your mental health.
Contribute to Open Source Software
One topic that came up in the panel discussion and that I’ve been advocating myself is how rewarding contributing to open source software can be. You shouldn’t contribute to open source project because it makes your GitHub profile look better, but because you’re genuinely interested in it.
By giving feedback to others and reviewing their contributions, you not only strengthen your programming skills, but also your ability to work remotely and communicate clearly. It definitely makes you a better engineer.
At the end of the panel discussion, Darragh Curran and the others all agreed that it’s OK to spend a day on a script to automate something in your workflow, because there are fewer human errors afterwards. You should definitely use tools to make your life easier wherever possible.
Just do it.
In addition to that, they remembered the attendees to always be curious, to always be learning. You should apply to positions even if it’s not the programming language you’re already very good in, but because it interests you. Find a place where you can learn it. Be patient, willing to learn and just do it.