5 Non-Technical Things That Made Me A Better Developer

I've recently been volunteering with some High School students at my Church and ended up meeting a brilliant young man who codes primarily in Javascript. He shared some of his repos with me on github and asked me to take a look at them. And it got me thinking about the lessons and tips can I give someone new to programming?

This is a two part article where I explore 5 non-technical tips to help a beginning developer and 5 technical tips to start incorporating in their coding patterns. This first part will focus on the non-technical tips, because they are more important.

1) Find A Mentor / Be A Mentor

Finding a mentor can be difficult. Being a mentor can be even more difficult. But I believe both of these roles are very important in a developers journey. It's easy to get wrapped up in our own little worlds of coding and not discuss challenges and solutions with others. But collaboration and teaching is crucial to developing ourselves beyond our little bubble.

So how do I find a mentor or someone to mentor? You have to be social with other developers. Here are a few ideas of how to be more social with your peer group.

1. Join discord groups
2. Join programming language specific sub-reddits
3. Attend user groups

2) Peer Review

What better way is there to get better at code, than to actually write some and have someone critique it? Peer review has gotten heat in the past for people being aggressive or mean in their PR comments, and so it can require a little bit of a thick skin. However, I've learned so much from people giving good constructive feedback. If you have a mentor, then they would be a good source of getting peer review.

I also believe that you can gain experience reviewing others code. However, this can be difficult. Avoid just rubber stamping their code and truly try to understand what they are trying to accomplish with their code. For any criticism of the code, remember to be respectful and constructive. That means that if you call out something for being wrong, suggest a better way to accomplish the task.

If you don't have a mentor and/or you are not comfortable with other humans reviewing your code, then I recommend at least getting an automated code review setup. Ruby has RuboCop, Javascript has various linters, and Dotnet has SonarQube. These automated peer-review systems can be really useful because they can provide a reason WHY they are dinging you as well as an example of how to fix your code.

3) Learn To Ask Questions And To Set Expectations

Understanding the requirements of the project you are expected to code is essential at being better at the craft. Let's face it, if you don't know what you are building, then how can you ever actually build it?

Gather information about the NEED (the WHAT)

1. Take notes when your Business Owner is describing their need. Like, literally write it down. This has saved my bacon countless times.
2. When first learning the need, don't focus as much on the HOW it will be done, but WHAT needs to be done. Once the NEED is clearly defined, then focus on the HOW.
3. Don't be afraid to ask questions about the process when you don't understand.

Once you've asked enough questions to gather sufficient requirements, it's time to set expectations on how the app will work and how long it will take you to build it.

Gather information about the HOW

1. When thinking of that HOW, think of examples of other apps doing a similar action and compare that to the need your Business Owner is explaining.
2. Spend time on mockups / wireframes. The visual is an easy way to set expectations and can be a good way to establish a look and feel contract with your Business Owner.
3. Write down all the requirements and refine them with your business owner.
4. Estimate how long it will take and commit to trying to get that work done in that time.
   1. Always try to under promise and over deliver.
   2. No capes allowed! You're not a super hero. Give realistic times that are fair to you.
5. Have your business owner agree to all requirements for a unit of work before starting any development.

This last tip is in bold because it's the most important. If you can't agree on what needs to be built and how it should function, then there is no point to building it yet.

4 ) Learn IT Operations In Tandem With Code aka DevOps

When I was younger, I hated learning all the boring Ops side that my apps would sit on top of. It wasn't until my mentor pushed the importance of learning ops and how integral ops is to the applications we build. There are many reasons for this dual learning.

1. You are not dependent on someone else to setup your infrastructure or CI/CD pipelines.
2. You can easily mimic the same infrastructure locally so that you have less "well, it works on my machine."
3. You can craft your code to work with the infrastructure. An example is using correlation id's to track a process across multiple apps / systems.
4. It provides more tools to handle difficult problems.
5. You increase your value to your current and future employers, and thus increase your leverage for salary.
6. Allow you to launch your own app without the need of someone else.

5) Learn To Manage Imposter Syndrome

Imposter Syndrome is anxiety from the feeling of not being good enough in your position despite being successful in your position for some time. This version of self-doubt has been a bit of a buzz word in the industry, but I think many still suffer from it.

There are several articles that go into Imposter Syndrome in some depth on the internet, and I'm not going to do a better job at explaining the problem and/or solutions. However, It's very important to overcome Imposter Syndrome and know your self worth in your industry.

It's important to know how much you do know and how much there is still to learn. I've been programming for over 15 years and I'm still learning new things. I still have to google really simple things all the time. But I know that I know some stuff, and that stuff is valuable. There's a fine line between being confident and being arrogant. You need to be confident and try to avoid comparing yourself to others.

Conclusion

I hope these points help you to become a better programmer. If they do help, leave a comment to let me know. If you don't agree, I would love to hear that also. Think of it like a bit of Blog peer review. Just keep it civil please.

continue on to Part 2
5 Programming Tips To Be A Better Developer