Coding Confidence: Senior Developer Insights

Johnb21 — Fri, 01 May 2020 16:35:37 +0000

I have never written a blog post of any kind. This is just as much a new experience for me as starting in development is for you. However, the goals of this post are to reach out anyone who may be new to writing code and give you a little perspective.

About Me

Just a quick blurb about myself: I am a Senior Software Engineer at a payment processing company. We specialize in making payment acceptance accessible for businesses of all sizes with both Mobile and Traditional solutions. My sole responsibilities include both API Development and Business Intelligence Solutions. Our core stack is a combination of nodejs, PHP, and Amazon Web Services.

I have been writing code for 10 years. I spent One Year on the Product Support team before moving into my Junior Developer role. I spent three years in that role before being promoted to a Senior Position. None of this was because I was the greatest gift in development since Bill Gates or Mark Zuckerberg.

Misconceptions

A lot of Junior Developers have this idea that if they want to be 'worthy' of a job in programming, they need to be able to code at 600 words per minute, be a touch typing master and be able to write an entire application - from start to finish - perfectly the first time and without issues. This is simply untrue.

You might have someone you admire and you watch their pre-recorded courses or YouTube Videos to learn about different technologies. It might seem like every amazing developer is capable of just typing out their thoughts as they go without any need to plan for construction. That is the power of editing. The best videos to watch are live coding sessions. These give a better insight into the thought process, planning and refactoring that is done. Albeit, these things aren't as sexy as just coding away - it's the reality of development.

Reading Docs

I talk with many developers - both online and offline - and the general consensus is ... nobody really goes long without reading documentation. There's no good way to fully commit an entire development language to memory; especially when technology and languages are fast evolving. Adding new features, deprecating features, etc. DO NOT be ashamed of having to refer back to the docs for things. There's a reason Google is the number one search engine amongst Software Developers ;)

Don't Be Afraid

There is always going to be imposter syndrome when it comes to whatever it is you're doing. "Am I good enough?", "ZOMG they're going to find out I have no idea what I'm doing!!"

I'm not here to break down the psychoanalysis of this thought process is - but you aren't alone. You have crossed the biggest barrier than there was to get into development ... WANTING to be a developer. That's pretty much it. You don't need to have some kind of burning desire to never stop coding; you don't need to dedicate nights and weekends on side projects; you don't have to take advice from these know-it-all Seniors (wink wink). You just need to want to do what it is you're doing. Go at your own pace, decide for yourself what it is you feel comfortable with and just be comfortable. You ARE good enough ... otherwise, you wouldn't have the desire to even be in coding in the first place.

Dev Process

This one is probably going to be the most difficult to explain because, let's face it, everyone is different. For myself (and I have discovered an entire community of people like this) - I will just try to get code in place that does the thing I want to do. I don't care about the coding principles; I am not paying attention to whether or not I have duplicate logic or whether I am constructing objects in the most architecture appropriate way. I just put something in and test to see that something works.

I have folders on my local machine dedicated to 'tinkering'. New concept added to the language? Tinker... Want to see if this string of methods works? Tinker ...

A lot of us will get the concept in place and see that we have success before paying more attention to the abstraction of the code and following design principles. Don't be ashamed to follow your own process. It's only code and it can always be refactored along the way.

End

I apologize for the long windedness of this post. I do accept criticism (I welcome it being that this is the first time I've done this ... ). Most importantly - I hope at least one person reads this and has more confidence going forward. If you have any questions or just want to tell me how wrong I am - please leave a comment below :).