Programming is a career that involves constant evolution and growth. We reached out to some of our sources to ask what tips they would offer to be a better programmer. We received some great advice from developers and people that manage teams, and of course, we couldn’t wait to share it with you.
Asaf Darash, CEO and leader developer of Regpack says you should never stop learning.
The mantra I repeat to myself and my development team often is: there is always something new to learn! Keep an open mind and remember there is always more than one way of doing something. Also, don’t be afraid to ask for help. We learn and grow from each other, so if you’re in a place where you are willing to share, learn new things and help others, you will succeed! This helps, in my view, to create and foster great developers and also a great team that works together. Especially in a fast paced environment, keeping up is easier if you remember to keep an open mind and ask for help.
Anthony Jullien, Director of IT at Dupray offers tips on keeping the user in mind.
Listen and understand the user’s need. Every developer has great ideas and concepts. Guess what? The majority of people don’t think like we do. We are extremely left-brain people. Remember that your ultimate goal is to make the user happy. If he or she isn’t, then they won’t be using your app.
Ensure that users are not lost. If a user doesn’t understand the app or interface, they sure as hell won’t be using it. If you are working on something complex, be prepared to baby them through the initial process.
Two great pieces of advice from Cameron Wilby, an instructor and co-founder at Origin Code Academy.
Find a mentor and be a mentor.
I got lucky – in my first job I had great mentors who were both rock-star programmers and awesome to work with. They taught me a lot about technology, building great software, having a good work ethic and working in a professional environment with a team of other developers.
Over the course of my career, I’ve made a point to “pay it forward” – to be a mentor to those who are looking to be mentored. It’s part of the reason I co-founded Origin Code Academy with Jeff Winkler, because I believe mentorship plays a huge role in not only distributing information in a fast-paced industry – but also helps you improve your own skills. One of the best ways to learn is to teach.
So I also recommend either finding somebody to mentor, or speak publicly at meetups and share the information that others have been willing to share with you.
Burnout is a very real problem in the software industry, and it’s not always down to how many hours you work.
There are developers who can work 90 hours a week and not feel stressed at all, and then there are developers who will work 20 hours a week and out of the blue suddenly feel a huge lack of motivation and discipline in their work.
The general consensus around developer burnout by those who have been there is that it occurs when the effort put in for a task does not equal the reward or feedback received. You pour yourself into a job because you love doing it – and you don’t feel appreciated.
How much reward and feedback you need is completely unique to you. You have to know what kind of person you are. Are you the type of person who gets motivated when somebody in the company sends you an email saying “Good job?” Or are you the kind of person who wants their work to be publicly acknowledged by the team to feel motivated?
This is a valuable piece of knowledge to know about yourself, but you have to realize that your actions can also be the solution to this problem for other developers. Everybody needs motivation – and you can help others avoid burnout by figuring out how they like to be appreciated, find something worth appreciating – and do it.
And who can forget about debugging? Daniel Domene, Principal UX Engineer at National Instruments, offers this advice.
People make mistakes. That’s unavoidable, so a HUGE skill is to be able to find those mistakes quickly and efficiently. Whether using WinDBG, XCode instruments, Visual Studio or KDB, it’s hugely underrated. When debugging, my secret is to only ask questions that would alter my next steps. It’s about having a theory and proving it. If I can test a hypothesis and with it eliminate half the things that could be wrong, that’s a good use of my time. On the other hand, if I spend time and effort to prove that the bug also happens on my coworker’s computer without a hypothesis, that’s a waste of my time.
What advice would you give to fellow programmers?